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ABSTRACT 


The United States Navy is currently implementing a plan 
to consolidate the wholesale supply functions of the Naval 
Air Station at Alameda and the Naval Supply Center at Oakland. 
Improving supply support of the Naval Air Rework Facility 
Alameda in general and stock availability in particular is a 
vital part of the plan. Demand forecasting by workload driven 
material requirements planning (MRP) is being considered as 
a means to improve stock availability. This thesis begins 
with an overview of the MRP technique and the current supply 
support of NARF Alameda. It proceeds with the description 
and evaluation of a temporary MRP system that is currently 
implemented and uses it as a background for development of 
meine System that is designed to operate in a maintenance 
Oriented environment in general and at NARF Alameda in 
Meeticular. Finally, suggestions are made for transition 


from the temporary to the proposed system. 
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I. INTRODUCTION 


The DOD Material Distribution Study (DODMDS) [7:8] 
attempted to determine the number and locations of wholesale 
activities necessary to provide efficient and cost effective 
distribution of materials. As a consequence of the recommen- 
dations of that study, the Naval Supply System Command (NAVSUP) 
initiated the Shore Establishment Realignment (SER) which will 
consolidate the wholesale supply functions of the Naval Air 
Stations (NAS) at Alameda, North Island and Norfolk with the 
Naval Supply Centers at Oakland, San Diego and Norfolk, 
respectively. 

NAVSUP has specified that the consolidation is not to 
degrade the supply support provided currently by the NAS supply 
departments. However, it will be beneficial to the system-- 
and especially to the Naval Air Rework Facility (NARF) as one 
of the customers--to achieve not only reduced costs, but also 
Biproved service. 

SER and the NARF's desire to maximize improvements has 
necessitated a basic reappraisal of the NARF/Supply System 
interfaces. The result [10] was identification of the fol- 
lowing problem areas and possible improvements: 


1. Response time,can be improved by:- 

a. Mechanized requirements submission 

b. Automated inventory control and materials handling 
2. Stock availability, can be improved by:- 


a. Demand forecasting by workload driven material 
requirements planning (MRP). 
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This study was done as part of the NARF's effort to 
clearly identify the problem areas inits supply support and 
find the best solutions to those problems. This study attacks 
specifically the stock availability problem and justifies why 
MRP is the solution. 

The implementation of MRP is integrated into the consoli- 
dation process and the implementation of response time improve- 
ments in the system. As a result, the implementation of MRP 
consists of two phases:- 

I. Implementation of a temporary system that will run on 
existing equipment and will be used to gain experience 
with the system and build up the necessary data files. 
This phase will include the design of the target system. 

II. Implementation of the final system on the new computer- 
ized material handling equipment--namely, NISTARS/ASKARS 


(Naval Integrated Storage and Retrieval System/Automated 
Storage, Kitting and Retrieval System). 


This thesis describes briefly the development and imple- 
mentation of Phase I and uses it as a background for a proposed 
design and integration of the final MRP system with the standard 


ASKARS software and database. 
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If. MATERIAL REQUIREMENTS PLANNING 


A. BACKGROUND: PRODUCTION AND INVENTORY CONTROL 

Production and inventory control emerged as independent 
management tools. Production control, in the very beginning, 
was one of the functions performed by the line foreman. He 
ordered materials, hired people and decided what, how and 
how much to produce. As his workload increased, the first 
task to be assigned to someone else was the ordering of 
materials. Along with that, there were also a few attempts 
to develop a scientific approach to production control. 
However, general applications did not develop prior to World 
War II. After the war, industry needed maximum production 
Since there was an almost insatiable demand for products. 

The main problem was how to make more and more products, not 
necessarily how to make them more efficiently [{1:XIII]. 

This environment gave a big push to production planning 
and many techniques evolved, mainly oriented towards pro- 
duction with little consideration of the related inventory 
problems. Among those techniques were Gantt charts [1:13.33], 
Line of Balance [1:13.23], Network Methods [1:13.33] and 
Linear Programming [1:13.45]. It seemed apparent that these 
techniques had great potential to improve both production and 
Inventory control which frequently deal with uncertainty, 
mepectally because of the little attention these functions 


had received from management. 
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Inventory control, on the other hand, developed in a 
meee Natural'’ way. The concept of economic lot sizing and 
reorder points was first presented by Ford Harris in 1915 
and later developed by R. H. Wilson in 1934 [14:3]. But it 
was only after World War II that that theory had seen real 
application, after stochastic inventory models were developed 
and could use this theory in a more realistic way. 

The biggest problem in applying the scientific techniques 
in industry has been the fact that companies were not ready 
for them because they had not begun to solve many of their 
basic problems in controlling production. Lists of materials 
and parts were not in existence. Production depended on the 
memories of people in the company. Under such conditions, no 
Scientific method which needed data could be implemented 
mie. lV}. 

The second decade after World War II has seen a reversal 
of that situation. Supply caught up with demand and low-cost, 
high-quality products were available in large quantities. 
Meeting competition required tightly controlled factories and 
Mest efficient use of men, money and materials. The responsi- 
bility to achieve the necessary improvements has been given 
Bete production and inventory control function [1:XIV]. 

Production and inventory control were separate functions 
with conflicting natures. Lack of data and experience was 
another problem. Together they created a problem too serious 


to ignore. 
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Miemintroduction of computers provided the means for 
solving many of the problems. The use of computers: 
1. Allows storing information. 
2. Enables processing and efficient use of that information. 


Seemakes the system more responsive because handling of 
@ata, Updating and retrieving are facilitated. 


feeertows integration of both production and inventory 
eentrol. 


fost attempts to use computers in production failed 
[17:3]. The main reasons were: 


1. Companies had failed to develop discipline in information 
handling. 


2. The system being implemented was a mechanized version of 
the manual system. Since the manual system was never 


taken seriously enough to work satisfactorily, there was 
no chance for the computerized system to succeed. 


However, those attempts established a sound foundation on 
which better systems were developed, supporting initially only 
Merts Of the various functions of production and inventory 
Sentrol. Later, integrated systems supported, or more accur- 
ately, maintained the whole production system. 

One of the techniques which emerged and benefitted from 
the use of computers was the Material Requirements Planning 
(MRP) method. This method, which is used as one module of 
maeeproduction and inventory control system, uses the pro- 
duction schedule as the basis for inventory control. By 
doing that, there are no longer two different systems, but 
one integrated system which: 


1. Uses the same data for both production and inventory 
moOmcrol . 
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2. Provides built-in mutual feedback and response in the 
system and no longer depends on activities of separate 
functions in the organization. 

B. MATERIAL REQUIREMENTS PLANNING CONCEPT 

Material Requirements Planning (MRP), or Requirements 
Planning System (RMS) as called by others [1:17.2], is a 
technique for determining the quantities of components that 
emiebe required to build a product or carry out a production 
schedule. 

The term "Components" is usually used to cover both sub- 
assemblies and parts from which a product is made. As far as 
the technique is concerned, there is no difference between 
them and the only requirement is to know that they are 
meemered to build the item and in given quantities for 
assembling one product. 

mmiendirect objective of the system 1S to generate require- 
ments in fairly precise time periods so that the right infor- 
[Meeton Will be available to get the required components into 
Meeeresular production process, rather than using lists of 
“hot items" to complete the assembly of an order. 

A manufacturing environment, as opposed to maintenance, 
1s the best for implementation of this technique because the 
output of the system is well defined in terms of the items 
being produced, the components from which they are composed, 
their quantities and their time schedule. Only a manufactur- 
ing environment can provide the inputs that MRP needs--with 


Sufficient accuracy--to ensure effective operation. 
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The MRP concept is described in Figure 1. The basis is 
the master production schedule, which is a "given'' to the MRP 
System. The production schedule states which products are 
to be produced and when. In addition to that, the system 
Miso USES two other files: 

meeuventory file - This file contains data about all 
items used/produced in the organization. The information 
about each item includes elements such as quantities (on 
hand, on order), sources of supply,price, lead times and 
associated costs. 

2. Bill of Materials file - This file contains the 
product structure data for each product which may be produced 
by the company. In addition to quantities of subassemblies 
and parts, the file will also contain numbers of drawings or 


other documentation required in the production process. 


MASTER 


PRODUCTION 
SCHEDULE 





MRP OPERATION 
REPORTS 


: PACKAGE 
BILL OF 
MATERIALS 
FILE 





— 


INVENTORY 
PLE 


Figure 1: A Material Requirements Planning System 
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The most important data item in these two files is the 
item identification number (part number). This is the common 
field that connects all files and allows direct access to get 
the required information for the computations. It is essen- 
tial to eliminate ambiguity in those numbers on the one hand 
and, on the other, to have meaningful numbers which may 
simplify operations of the system and prevent mistakes. 

The process by which requirements are determined is as 
follows. First, the master production schedule is used to 
determine which products will be produced in the following 
period. For each order, relevant data from the bill of ma- 
terials file is retrieved and added to the "file'' of required 
ieeerials. At this point, each product is “exploded" into 
its basic components and total quantities are computed for 
each item (part number), 

ft iS important to note that the production schedule for 
more than one planning period can be used. But since the 
mame the items will be needed is very important (it might be 
very costly to keep them when not needed), we would like to 
sum up requirements separately for each period and as close 
as possible aoe day of use as lead-time allows. Adding 
mieerequirements for all periods and orders gives the "gross 
requirements,'' i.e., a list of all components required to 
Barry out the production schedule. 

When the gross requirements are available, they are com- 
pared with the information in the inventory file. For each 


item, the gross requirement is compared with the total of 
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quantities on hand and those on order which are due in the 
relevant period. If the gross requirement is greater, an 
order should be placed. A simple rule to determine the 

order quantity suggests itself--order the amount which is 
missing. Thus, it may be that the same item will be required 
for the next period also. This requires a more sophisticated 
rule which will be discussed separately. 

The way the process was described is most fitting 
when there are no deviations from the production schedule. 
Obviously, this is not always the case. As it turns out, 
the same logic can also be used in a continuous operating 
environment (including deviations from schedule) by regen- 
eration of the requirements as described above. In other 
words, the updated production schedule is used periodically 
mmenecompute the requirements. This process is called a 
schedule Regeneration System [4:99]. 

Another way to compute requirements without repeating 
all computations for periods which were previously analyzed 
is Called the "Net Change Material Requirements Planning" 
[4:102]. The basic idea here is to keep track of the orig- 
inal gross requirements for each period and then to compute 
faoos requirements for changes in the production schedule 
as they occur by adding/subtracting them according to the 
Specific change in the schedule. This results in a new 
gross requirement which has to be compared to available 


Stocks (on hand and on order) to give the net requirements. 
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The computation is relatively simple when the change is 
an addition of a job, but it becomes very complicated to keep 
track and "to free" allocated materials when the change is a 
deletion of a planned job. 

It may seem that the 'net change" alternative is much 
better than the regeneration system. This is true if there 
are no changes in the schedule. But if this is not the case, 
continuous updating of the whole data base is required along 
with the necessity for incessantly reacting to the system's 
S@tpuc. That usually creates a ''nervous" reaction of the 
system, i.e., order changes and manual follow-up, which is 
more a disadvantage than an advantage. Of course, there is 
always the trade-off between the "nervous reaction" and the 
lack of reaction of the system. A short (one month) cycle 
time (planning horizon) may provide a good compromise, thus 
justifying the use of the simpler regenerative system. 

Figures 2 and 3 describe the "regeneration" and net 
change alternatives. From the flow charts it can be seen 
that the "net change" algorithm is more complicated. But 
if there are only few changes in the production schedule, 


some work may be saved. 


See osUMPTIONS AND PREREQUISITES 

Introduction of an MRP system as an inventory control 
tool in a manufacturing organization is not just a matter 
of management's decision. There are some assumptions and 


prerequisites about the environment in which MRP is to 
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be implemented. The preconditions for implementation of 
MRP are listed below: 
hm Existence of Automated Data Processing (ADP) 

The amount of work involved in manual computation of 
requirements is prohibitively high. A manual MRP is imprac- 
tical except for very simple products. The assistance of 
computers is required for processing of massive numbers of 
Tower-level items. 


2. Existence of a Master Schedule, Bill of Materials 
perlewand Inventory Status File 


These files are the basic input for the MRP systems 
and it 1S obvious that without them the system would not work. 
But the existence of such files is not enough because files 
Can have these names and contain different data than needed. 
ime Master Schedule should be stated in terms of entries in 
the Bill of Materials file (BOM), i.e., having a product to 
be produced allows access to the Bill of Materials file to 
get a list of components and quantities required to produce 
that item. <A similar relationship should exist also between 
the BOM file and the inventory file to obtain the status of 
een component needed. The common key here is the Item 
Meentitication Code (IIC). 

3. Unambiguous Item Identification 

This is usually achieved through unique codes such as 
Merce numbers. Although this subject seems to be straight- 
forward and simple, it is actually very difficult to maintain 
a simple unambiguous identification method when dealing with 


hundreds of thousands of items coming from many sources. 
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fe Data Integrity 


Files must be kept updated and consistent with each 
other. Changes in design require changes in the BOM file and 
Meemecilt in changes in quantities to be ordered. Therefore, 
all files should be updated simultaneously since changes in 
one may cause changes in another. 

5. Known Lead-times 

At the very least, there should be estimates of lead- 
memes) tO allow reordering on time. 

6. Availability of Components 

All components of a product must be available when 
the production order is released. Although this assumption 
may not hold in some cases, it may result in simplification 
Of the MRP model. A more complicated version may take into 
account the production schedule for a specific item and allow 
menaval Of certain items during the production process. This, 
of course, is more difficult to implement and the benefits are 
outweighed by the problems it causes [4]. 

lmeeecocess Independence 

[t is assumed that there is no interference between 
feererent production orders. The production master schedule 
Should incorporate all relevant considerations. 

The existence of all these factors in an organization no 
more implies the applicability of the MRP model than their 
absence implies their inapplicability. Basically, an MRP is 
"applicable to manufacturing environments that are oriented 


towards fabrication of components" [4:42], and the problem of 
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Satrstaction of preconditions may be solved if the decision 


is made to implement MRP. 


week SYSTEM OUTPUT 
What is the MRP system expected to produce? Basically, 
every production/inventory control system is expected to 
provide the Inventory Control Manager with information that 
will answer the following three problems: 
il What to buy? 
fee when to buy? 


3. How much to buy? 


The question of what to buy gets a straightforward answer 
Peemeethne system by computations of gross and net requirements. 
This is a "simple'’ decision when the production schedule is 
meewmeand the composition of each product is fixed. Those 
two factors are preconditions of the MRP system. 

The problems of when to buy and how much to buy are more 
complicated and interdependent. The decision may be affected 
Dy Many external factors such as sale prices, seasonality, 
expected shortages because of instability of the market or 
Other similar factors. Of course, such factors cannot be 
@eeounted for in a system which runs according to a prede- 
termined algorithm because they apply only to specific items, 
and the only simple way to improve results is to correct 
manually the "proposals" of the system. 

However, there are other factors which determine the 


quantities and timing. The basic factor is, again, the 
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feemerion schedule. When it is split into specific tasks, 

an exact determination can be made as to how much is required 
at any point of time. When inventory (on hand and on order) 
is compared against requirements, the result is information 
about definite quantities which are to be available at certain 
times. Consideration of lead times gives the time for order- 
mg . 

The decision whether to follow that basic ordering 
Meme has still to consider trade-offs between ordering 
meees and hoiding costs since the same item may be required 
for more than one period of time. 

That problem is solved by the least unit cost method 
(4:511] which calculates the combined ordering and holding 
cost per unit for each period separately, for two periods 
Combined, for three periods, and so on, and selects which- 
ever method produces the lowest unit costs. 

Even though we have discussed the output contents before, 
mesnould be recognized that the way it will be presented 
depends on the user (and the ADP responsiveness, of course!). 
memthe Organization is highly computerized, and its procure- 
ment activities interact with organizations which are also 
highly computerized, it is. likely that the output will be 
magnetic tapes which will contain all purchasing orders. 
These tapes will be sent to the sellers, which in turn enter 
them directly into their automated system. (Such a method 


is used for procurements in the Israeli Navy.) 
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if the system is not that well developed, the purchasing 
order containing all data required to buy the item will be 
mramted by the computer. Those orders will then have to be 
reviewed and processed. 

The MRP system may also produce many other management 
reports. These will usually concern specific problems which 
m—estein the plant. Typical reports of this kind are: 

ieee exception Report 

firs nepOrt presents exceptional events (shortages 
or unused inventory) which should be reviewed by someone. 
feinavility to Meet Production Schedule 
It may happen that the production schedule was 
determined without checking its feasibility. If so, the 
schedule is impossible to follow because of shortages/long 
Head times. 
fee inquiries 
ifescmeansbe helpful to the production scheduler to 
prevent events which will later appear as an inability to 
Meeteschedules. Direct access to the system files using the 
mereatcorithm may help the scheduler to decide if inclusion 
Ot 2 production order in a certain period is feasible or not. 

The specific outputs should be tailored to the needs of 

the specific users and the capabilities of the system on 


which MRP will run. 
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E. MRP AND CONVENTIONAL INVENTORY CONTROL 
There are many good reasons for holding inventories. In 
a manufacturing environment the most important reason is to 
prevent production shutdown and allow smooth operations. 
Various techniques were developed to control inventories in 
Order to optimize (by minimizing total costs) operations of 
the whole system. 
Among the most famous ''conventional" inventory control 
methods are the following: 
1. Perpetual (Continuous Review) System 
Two inventory levels (RO = reorder objective, ROP = 
reorder point) are determined for each item. Inventory status 
1s reviewed with each transaction and when inventory reached 
the ROP level a fixed quantity (RO- ROP) is ordered. 
fe lwo-Bin Inventory System 
This iS a simplified continuous review system. The 
ROP is the quantity held in one bin and the RO is the quantity 
in two bins. When one bin runs out of stock, the quantity to 
fill it is ordered. 
3. Periodic Review 
This system reviews inventory status at fixed inter- 
Vals of time. Upon review, an order is placed for the quantity 
Begaired to bring inventory to RO. 
4. Optional Replenishment 
This is also a periodic review system, except that 
an order will be placed only if inventory is less than a pre- 


determined quantity (ROP). 
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fm those policies use the basic ""EOQ model" with 
appropriate adjustments of its assumptions to real life. 

After selecting the model, the required data is found (or 
decided upon by a “rule-of-thumb") and used to determine the 
Seeder gduantity,'' the "reorder point" and "reorder objective." 
Since the models are used to determine "what, how much, and 
when" to buy in the present and for future use, all of those 
meeimaques have to use forecasting methods to estimate future 
demand and that forecast (based on past demand) becomes the 
basis for all future operations. 

On the other hand, MRP uses the production schedule which, 
of course, provides a sound basis for the computations and 
promises smaller deviations from the plan to actual performance. 

That advantage also has a price. In order to be. able to 
operate an MRP system, a production schedule is needed in 
advance and, for each product, the system has to have an accur- 
ate bill of materials. This is not the case with the other 
techniques. Since they do not depend on a specific production 
plan, they have no need whatsoever for the master schedule or 
bill of materials. All that is needed is past demand trans- 
lated to a forecast which helps to determine all inventory 
imevels. 

Another major difference lies in the behavior of the 
Systems in an-environment of changing products. In such a 
case, conventional methods may cause a build-up of "dead-- 
stocks'' and shortages in the required new items, whereas MRP 


mel '’sense' that in advance and stop ordering the items not 
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needed and prepare the required materials. Because of those 
changes, traditional techniques also suggest higher safety 
stocks. 

Generally speaking, MRP will be more responsive to pro- 
duction because of the fact that it uses the same plan and 
meme@eive--the production schedule. This 1S not so with the 
traditional methods which do not consider it at all. 

In summary, when comparing MRP to other conventional 
production and inventory control systems, one can identify 


the following advantages and disadvantages: - 


ADVANTAGES DISADVANTAGES 

1. Based on production 1. Requires a production 
schedule schedule 

2. Allows small or no Z. Requires a large, high 
safety stocks quality data base 

3. Responsive to changes 3. More complex, more 
in demand difficult to use 

4. Easily identifies Aeere wd ti rrenlt to 
"excess'' items implement 


5. Does not have to 
Keep historical data 
This comparison shows that MRP has advantages as well as 
disadvantages. Before a decision is made to implement it, 
all factors have to be considered to determine that the 


investment (money and effort) is worthwhile. 


F. IMPLEMENTING AN MRP SYSTEM 
Before addressing the specific problem of implementing an 
MRP system, a few words should be said about implementation 


of an ADP (Automated Data Processing) system in general. 
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The process of implementation usually begins with the 
very first idea about system change and it terminates when 
the system has been successfully integrated with the opera- 
tions of the organization. This process involves the study 
of the new desired application, determination of the objec- 
Pives, participation of the future users in the design of 
the ''new'' system and selection of the steps and timetable 
to change the system from its present configuration to the 
desired one. 

In this specific case, the steps which will be addressed 
are the initial study prior to the decision to proceed to 
actual implementation, the various considerations which 
Should be discussed in that analysis, and the basic steps 
towards implementation. 

The first problem that should be addressed is whether 
the system is mature enough for MRP. The problem is not one 
of satisfying prerequisites, but whether the change to MRP 
is too big for the organization. Nolan and Gibson [3] iden- 
mrcy four stages in the growth of EDP systems in terms of 
the applications, EDP personnel, and formal management tech- 
Migues applied to each. The four stages are:- 


1. Introduction of simple applications (such as payroll 
and accounting). 


Z. specialization to develop a variety of applications. 
3. Moratorium on new applications and emphasis on control. 


4. Specialization for data-base technology and tele- 
peocessing. 


Each succeeding stage requires more skills, more sophisticated 
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techniques, and a more mature environment than its predeces- 
sors. In order to proceed to a higher stage, there should 
be experience with lower-stage applications which naturally 
form the basis for evolution. In the case of MRP it will be 
obvious that the organization should have previous experience 
in developing and using at least separate systems for produc- 
tion and inventory control. At this point, the problem will 
involve "only" their integration and not the much more compli- 
cated problem of creating and integrating an advanced system. 
Given the environment, the existence of fundamental skills 

and the acceptance of the decision and its justification, the 
following actions are to be taken: 

1. Analyze available and required input for MRP. 

2. Design the new MRP system. 


3. Identify required changes in existing data files and 
their relations to other applications. 


4. Determine specific output from the MRP system. 


5. Identify required changes to existing software and 
development of new programs. 


6. Develop or buy software: "make or buy!’ 


7. Prepare a plan of how to switch from one system to 
the other. 


8. Train personnel. 
meepnepare a timetable for carrying out those actions. 


mieecarry out that plan. 


The first problem that comes up after knowing what to do 
1s deciding who will do it. It is possible to assign the job 


to either an outside consultant or to the organic EDP department. 
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Although bringing in an expert may sometimes cause troubles 
(especially dissatisfaction of in-house personnel), this 
might be a good solution. On the other hand, using the 
organization's people develops their skills, makes use of 
their familiarity with the system and prevents the problem 
of later being left to maintain a system which was developed 
by outsiders. 

Another problem is that of designing the new system. It 
1s desirable to have the users participate in that process 
and contribute their knowledge of existing problems and sug- 
gestions for system improvement. A steering committee, 
composed of users and EDP people, can serve as the body to 
gather essential information about the old and new systems. 

Two other problems are interrelated. These are the 
problems of changing existing software and developing new 
programs. There are MRP software packages. However, the 
problem with these software packages is that they were not 
designed for the specific user that is going to use the 
System, and since the software package is not flexible, it 
Meee require changes; this, of course, should be avoided. 
The same rationale should also be used to avoid unnecessary 
expansions. The developers should concentrate on the minimum 
expansion and changes required to accomplish the objective 
but avoid making them too restrictive and inflexible with 
meopect to later developments. 

An important factor in the development of the new system 


1s planning the process of switching from using the old system 
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to the new one. It is highly desirable not to implement all 
changes at one time. It would be better to first change the 
Merudeture of the data files and to continue using old programs 
(although that also requires minor changes), then: 


i Use converted data files to develop and test new 
software. 


2. Run old and new systems in parallel. Compare test 
files and outputs with current system. 


3. After new software is error-free, stop using the old 
system and transfer to the new one. 


This sequence allows better testing and smooth switching 
without having to cope with many problems ("'bugs,'' human 
Mero tance, lack of experience) ina short and crucial period 
of time. 

Another decision that must be made concerns which version 
Ot MRP to choose: "net change" or "regenerative" system. The 
Penal Output is going to be the same, but the EDP problems 
encountered in the net change system are much more complicated. 
Memrequires keeping old schedules and their back-up files, 
generation of new files for the updated production schedule 
feeetinally, their comparison. In addition to the fact that 
mans data processing is more complex, special attention is 
also required any time changes are made to files or programs. 
This makes the system more sensitive to "'bugs'"'--a highly 
Baagesirable state of affairs. 

Another subject which should be analyzed at this time is 
the introduction of advanced data base management systems. 


Traditional information management is based on keeping many 
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dedicated files of data related to specific subjects such as 
inventory status, finance, production schedules, statistical 
files or personnel records. That concept simplifies manag- 
Meweach individual subject but creates duplications in 
information reported and held, which usually results in 
conflicts. On the other hand, the new concept is to have 
one comprehensive data-base holding all interrelated data. 
There are special software packages which support mainten- 
ance of data bases (IMS, IDMS, TOTAL, ADABAS and others) and 
using them may help to create a sound basis for a good MIS 
(Management Information System). The planning period before 
transition to MRP is a very good time to investigate the 
possibility of moving to one central data base. The reason 
is that MRP needs well coordinated files of inventory status, 


production schedules and bills of materials. 


As mentioned earlier, the MRP system needs very accurate 
and consistent files requiring a very careful processing of 
Gata (especially the BOM) before operations begin. Since a 
Similar process is required when converting to a modern 
data-base, it is recommended to combine both into one step 
and make sure that the conversion is done carefully and 
eompletely. 

A very important factor which must be kept in mind dur- 
ing the whole process is the human factor. Implementation 
of an MRP system is going to affect the users of the system 
(inventory managers, production managers and other functions) 


and the ones who are responsible for implementation (EDP 
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and others). Those people must be involved in the process, 
asked to contribute, be trained in system operations and 

be made to feel a part of the system. The system may require 
changes in working habits and procedures and their coopera- 


tion is essential for success. 


G. CONCLUSIONS 

The discussion so far has addressed a pure MRP system. 
Mmeecoes 1t exist in a real life situation? Pure MRP is 
unlikely ina real situation. There are only a few organi- 
zations where the MRP system will be able to cover all 
materials used. Since the others must also be managed 
somehow, a compromise must be found between traditional 
methods and this one. That combination is necessary espe- 
Cially in organizations whose work is not pure production, 
even though the work may be of a repetitive nature. This 
can be the case of a shipyard or a repair facility which 
also produces some items. 

The nature of repairs is that there is not an accurate 
"Bill of Materials" for repair of a given item, although 
averages and standard deviations may help represent the case 
meme pseudo-production." This is particularly true about 
inexpensive spare parts (bolts, nuts, fuses or other "con- 
sumables'") which have a high total demand, but also high 
deviations in requirements for repair of certain items. 

The best way to act in such an environment is to combine 
MRP with the regular EOQ models. This will require classifi- 


Cation of items according to the system which is used to 
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Gontrol them. Items which are inexpensive and "high-movers"' 
can be controlled by the simple EOQ model, whereas more 
expensive items, which are not common to many systems and 
have low (and discrete) demand, can be treated by the MRP 
system. 

It may appear that this combination is more complicated, 
but it turns out that the input required for MRP already 
provides the input for the simple EOQ model and the overhead 
from having another module is overridden by the extra benefits 


that the combination gives. 
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Pils SUPPLYSSUPPORT OF NARF ALAMEDA 


The intent of this chapter is to describe the "present" 
supply support of NARF Alameda, the concept that underlies 
this system, the data-base and computer resources used in 
this process, the weak points of the system and elements that 
mequire improvement. 

Phase II of the San Francisco bay area SER is now underway 
and it is somewhat difficult, however, to be exact in this 
Mescription of the "present" system because of the: consolida- 
tron and the continual changes resulting from it. There will 
be an attempt to distinguish between activities which existed 
prior to consolidation and those resulting from consolidation. 
Mieeverything goes according to the original schedule [7:19], 
the present system with temporary, pre-NISTARS improvements, 
will last throughout April 1981. 

Figure 4 depicts both pre and post consolidation requisi- 
tion channels of NARF Alameda and provides a framework for 


the description to follow. 


A. CONCEPT AND OPERATION 

The concept applied for the supply support of NARF Alameda 
Memene Area Support Concept [9:III-15]. This concept is gen- 
erally employed in geographical areas surrounding NSC's and 
NSD's where the customer activities are nearby. According to 


this concept, the customer--in this case the NARF--does not 
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stock items [9]--except nonstandard items or expense item 
material--and whenever items are needed they have to be 
requisitioned through the requisitioning channels. 
ieee re-Consolidation Support 
Prior to the consolidation, the NARF shops had three 

sources of supply: 

a. The NARF's NIF (Navy Industrial Fund) Stores. 

b. NAS Alameda--for aviation items. 


c. NSC Oakland--for other items. 


Bach of these sources has different stocking policies and 
meocedures to determine the items to stock, order quantities, 
mmeereorder points. 

aeee NIE Stores Items 

Items stored in the NARF's storerooms are deter- 
mined by the NARF's material planning personnel. However, 
approval for establishing items in the Alameda stores is 
Mestricted to material section heads or higher. The material 
planners are allowed to establish NIF stores items with mini- 
mum demand frequency of six per quarter and maximum unit price 
of $25. Order and reorder quantities are determined by the 
material planner using his experience and the technical data 
(drawings) available. 

A major portion of the material support for the 
gndaustrial operation is provided by the Pre-Expended- Bin 
(PEB) operation. It contains high usage, low-priced items 
that have been expended from stock records and charged to 


Overhead at the NARF. The NARF also maintains physical 
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records of materials provided by customers for use on their 
own jobs. 

The NIF Store operation is basically a manual 
m@eration. As a resuit, there is not any (recorded) historical 
demand data to be used for more intelligent demand forecasting 
Seeimventory control. This is going to change with the intro- 
duction of the Naval Air Industrial Material Management System 
(NIMMS) that will be described later on. 

b. NAS Alameda 

Before the consolidation, NAS Alameda supported 
the NARF as a wholesale customer for IR Cog material and as 
a retail customer for the 9 Cog and SPCC managed items. The 
wholesale stock levels were maintained by ASO. Unfilled 
NARF requirements were transmitted to ASO for referral, pro- 
curement or other action as required. 

On the other hand, the NARF's demand for retail 
material was provided for by the VOSL (Variable Operating and 
Batety Level) model. The disadvantage of VOSL in this case 
is that it uses historical demand to forecast future require- 
ments. In reality, NARF demand is dependent on the production 
schedule of the NARF. For example, during the second quarter 
meery ‘79 the Point of Entry (POE) supply effectiveness (i.e., 
the ratio of requisitions that were filled and the total number 
of requisitions entered into the system) of NAS Alameda was 
95.2 percent for IR Cog expense items, 74.4 percent for 9 Cog 
items and 55.7 percent for SPCC managed items [21]. These low 
figures appear to be a result of the model discrepancy, as 


described above. 
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Gee NSC Oakland 
NSC Oakland was NARF Alameda's source of supply 
for the 9C, 9D, 9G, 9N and 9Z Cogs. NSC Oakland is a Special- 
ized Support Depot (SSD); that is, an activity with a special- 
ized mission as to the type of material or scope of support. 
Its stock replenishment is centrally controlled by the 
Cognizant Defense Logistic Agency (DLA) Item Manager (IM). 
stock replenishment is based on historical demand. 
Similar to the situation at NAS Alameda, this 
policy does not seem to fit the case. 
@. Post-Consolidation Support 
Phase II of the consolidation (administrative consol- 
idation) is currently being implemented after phase I (plan- 
ning) has been completed. Its most significant effect is the 
fact that NAS Alameda no longer supports the NARF, and the 
only external source of supply is now NSC Oakland. It also 
becomes the replenishment source for the NIF Stores inventory. 
PomlemeLoned Carlier, this period is an intermediate 
period that will last until the installation and integration 
of the NISTARS at NSC Oakland and ASKARS at NARF Alameda. 
ame NIE Stores 
The consolidation has no direct effect on the NIF 
Stores except that their stock replenishment will be now only 
from NSC Oakland (NSCO) and not from NSCO and NARF Alameda. 
However, the implementation of NIMMS requires the appropriate 
interfaces to NISTARS and ASKARS so that savings from the 


improved control and usage of recorded data would not be 
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degraded by additional work (caused by old processes) when 
items are replenished, stocked or retrieved. 

The NIMMS software package is designed to process 
inventory transactions and does this through an Inventory 
Balance File and a Transaction file. Those files are used 
Momproguce management reports, especially the "NIF Retail 
Store Stratification" report in which reorder levels are 
updated, and the "Automatic Replenishment"--which uses those 
levels and the on-hand quantity. 

The function of automatic replenishment requires 
an interface to ASKARS and NISTARS, to obtain information on 
mremrequisitions' status in order to determine when replenish- 
emt is required, and later, to direct the material for stock- 
ing in ASKARS. 

b. NSC Oakland 

iMrewechaneesin the organizational structure by 
itself would not improve the availability of items required 
by the NARF. In fact, there are many items that were not 
carried by NSC Oakland before the consolidation and will have 
moO be carried afterwards. 

Items for the NARF will be separated from the 
regular NSC stock (Sometimes physically and sometimes only 
logically) into a Ready Supply Store (RSS). The range and 
Mmeeen Of the RSS stock will eventually trade the actual de- 
mand instead of forecasting demand only according to histor- 
ical demand. The actual demand will be forecasted by the MRP 


model using the BOM information and the production schedule. 


43 





take 


were 


The implementation of RSS and MRP concepts will 
Peace in three phases: - 


Establishing the RSS and its initial stock levels, as 
described below. 


Change RSS operation to level settings by "temporary" 
MRP. 


. Approval, implementation and operation with the pro- 


posed MRP system. 
Since the temporary MRP data base and software 


not ready on ll November 1979 (the day of establishing 


the RSS) a "rule of thumb" was used [19] to determine the 


@nitial RSS stock. The procedure to set those levels was 


as follows:- 


1 


Identify all customer orders that will be worked in 
my ‘S80. 


memekhate a list of "'candidate" NIIN's by searching the 
NARF's POE demand for those customer orders in the 
last three quarters. 


Delete from the list any NIIN that does not belong 
EO, One Of the following Cogs: 9Z, 9N, 9G, 9D, 9C. 


Add items for the following four special support 
programs: F62 engine, TF34 engine, 50K-17 engine and 
moe alrcraft. 


For all items in that list, compute the NAS Alameda 
protected quantity (stock to support the NARF and 
Squadrons for one quarter, computed by VOSL). 


Bplitethe protected quantity: $5 percent for NARF and 
15 percent for retail protected quantity. These 
percentages were determined by the share of the NARF's 
requisitions out of all requisitions filled by NASA. 


. Compute the initial RSS quantity for the item as the 
maximum of 0 and the difference between the NAS Alameda 


on-hand balance and the retail protected quantity. 
Write an AOA ("fill or kill") requisition automatically 


for all items with a positive initial RSS quantity (for 
tia ceratamG1 Cy). 
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The reasons for using that simple procedure were 
mainly the short time available and the ''need" to prevent its 
decapitalization to DLA owned stock at NSCO. It also saved 
a lot of time by generating the requisitions by software and 
not manually. 

The introduction of the RSS required changes in 
the NARF's requisitioning procedure to NSC. Instead of merely 
Submitting a requisition to NSC, the NARF now has to first 
mearormine if the item is available from the RSS stock. If 
sO, the requisition will be directed to the RSS; otherwise, 
Meret be referred directly to NSCO wholesale stock. A 
terminal communication network allows on-line inquiries 
against both RSS and wholesale stock. 

The integration of the temporary MRP system will 
occur gradually as that software and data base are expanded. 
The requirements for the second quarter of FY80, generated 
by MRP, will cover only the F/E and engine programs. The 
requirements for the other programs will be determined manually 
and added to those generated by MRP. Afterwards, the require- 
ments for the third quarter of FY80 will be generated by MRP 
for all programs. These requirements will be checked and 
updated manually by the material planners before submission 
to NSC Oakland. 

The process of determining and submitting require- 
ments to NSCO can be further improved with the implementation 


of the proposed MRP system. 
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B. AUTOMATED DATA PROCESSING OVERVIEW 

As described earlier, prior to the consolidation both 
NSC Oakland and NAS Alameda were involved in supply support 
of NARF Alameda. One of the implications of having two 
"Suppliers" was that both activities had to carry out similar 
inventory management functions, i.e., both activities had to 
process separately the same kind of transactions and maintain 
the same kind of files, both referring to the same customer-- 
NARF Alameda. Both NSC Oakland and NAS Alameda use the same 
inventory management system: the Uniform Automated Data Pro- 
cessing System--Stock Point [UADPS-SP]. After the consoli- 
dation, NSC Oakland becomes the only direct supplier for the 
NARF. 

With respect to data processing, it means that NSCO's 
data processing department will do most of the data processing 
of data relating to the NARF. However, in addition to pro- 
cessing done by NSCO, there will be some inventory management 
data processing by the NARF itself. This may involve running the 
MRP application and generating the requirements to be sub- 
feeeced to the NSCO. 

This section describes NSC Oakland's data processing 
systems. Details on data processing and DP equipment at NARF 
mame da are given in the chapter describing the temporary 


MRP application. 


ieee Data Processing Equipment and Applications 
at NSC Qaklan 
NSC Oakland is one of several of the Navy activities 


using the Uniform Automated Data Processing System--Stock 
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meme (UADPS-SP). UADPS-SP is the standard software package 
used by Navy stock points to carry out the various inventory 
management functions. However, inventory control is only one 
of the applications run by NSCO's Data Processing Department 
(DPD) as UADPS-SP. The major applications are the following 
ones: - 

1. Inventory Control. 

2. Requisition Control. 

Seerinancial Inventory Control. 

4. Stores Accounting. 

§. Civilian Employees Payroll. 

6. Supply Overhaul Assistance Program. 

7. Labor/Cost/Allotment Accounting. 

8. Procurement and Procurement Accounting. 

The list of applications is so long mainly because 
UADPS-SP was developed during the early 1960's, and although 
it underwent several improvements and modifications, the 
System is still using concepts and equipment from that period. 
As a result, instead of having one integrated system, the 
Bsystem'’ is composed of a set of related applications that 
use many traditional files (as opposed to an integrated data- 
base and a data-base management system), many old-fashioned 
programs and processing runs and a variety of data processing 
equipment. Appendix A gives a list of selected UADPS-SP files 
which, as mentioned earlier, are only part of the data-base. 

In addition to the above list of applications, the 


DPD runs also a telecommunication system. The network has 
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terminals in the San Francisco bay area and at other Navy 
facilities, and provides inquiry services relating to inven- 
tory and requisitions and data-entry for material storage/ 
receiving and for procurement. 

The hardware consists mainly of a dual system: a 
Burroughs B-4800 CPU and a Burroughs B-3500, a peripheral 
switching unit that helps sharing the peripheral devices by 
both CPU's and thereby improve their utilization. The 
B-3500 is used with a front-end processor (Burroughs B-874) 
for communication, whereas the B-4800 handles the batch- 
processing applications. The non-inventory control applica- 
tions are handled by a Honeywell H200 computer, a Wang 
computer and an IBM 360/20 card-system. Most of the termin- 
als used in the communication network are Burroughs products 
(TD-800, TD-700, TC-500). Until recently some non-Burroughs 
terminals were also connected to the network (Zentec and 
Hazeltine). The system also includes three line printers, 
two card readers, two card-punchers and a variety of conven- 
etonal equipment. 

The DPD operates in three shifts, seven days a week 
and, according to the DPD director, the equipment is utilized 
to 90 percent or more of its capacity. The major implication 
Meethnis fact is that it is very difficult to add new applica- 
tions to the system and also that equipment failures can 
generate severe backlogs in the system. 

Another import aspect of the operation of the DPD 


is that it usually does not develop its own software. 
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Only applications that are simple and local in nature are 
written by local programmers. 
2. The Inventory Management Subsystem 

The UADPS for stock points is divided into three 
subsystems, each consisting of one or more applications and 
each serving a logical group of stock point functions. The 
maree subsystems are:- 

1. Activity Management (Designator A). 
Z. Inventory Management (Designator I). 
3. Data Processing Environment (Designator D). 

The highest level of interface between the functions 
performed at a stock point and the UADP System is at the 
Seerreation level. In UADPS terminology, the term "appli- 
Cation’ is arbitrarily used to define those data processing 
actions which supplement the manual actions necessary to 
Carry out a given function. Consequently, what is usually 
referred to (not in UADPS) as inventory management (applica- 
tion) is in UADPS terminology a subsystem and is composed of 
several applications. 

Each application is subdivided into a variable number 
of operations which are defined as one or more ADP runs per- 
formed to produce a given major product or result, e.g., 
produce a given report, process a specific type of transaction, © 
etc. The large numbers of applications and operations, and 
the fact that those operations are scheduled manually, explain 


Why it is so difficult to run the system. 
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The following applications comprise the inventory 


management subsystem: 


it 


Customer Information (designator IA) involves the 
actions required to provide information of any nature 
mecustomer activities. 


Peecipt/Due (designator IB) involves those actions 
peeinning with the establishment of a due-in through 
receipt of proof of storage. 


. Issue/Demand pe cess ans (designator IC) begins with 
me receipt of deman ocument and continues through 


the preparation of a referral order or issue document/ 
picking ticket and proof of issue. 


Inventory Control (designator ID) includes manipulation 
of demand data to set stock levels, determining replen- 
ishment requirements, reconciling replenishment back 

@maer requests, and processing replenishment documents. 


euartty Control (designator Ii) involves stock record 
@eemracy, including location audit, physical inventory 
and physical inspection of stock. 


Busposal (designator IM) involves computation of excess 
quantities and follow-up on disposal and/or shipment 
of excesses. 


Automated Ready Supply Stores System (designator IN) 
involves the supply an inancial management and 

recordkeeping functions for RSS. NARF Alameda's MRP 
system will have to interface with this application. 


Records Maintenance (designator IP) involves those 
actions,necessary to maintain accurate mechanized 
records. 


Repairables Management (designator IR) involves the 


actions necessary to induct NRFI (Not Ready for Issue) 
material into a repair facility and to maintain 
Somtrol throughout the repair cycle. 

Data Files 


The inventory management subsystem uses and updates 


most of the files in the data base. Of special importance 


are the Master Stock Item Record (MSIR) file and the files 


which contain customers’ requisitions: the Requisition Status 


File (RSF) and Demand History File (DHF). 
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The MSIR is a variable length, direct access record 
Gemesining stock status data for each item carried in stock 
at the activity. Data elements relevant to identification, 
Semtrol, storage, and quantities of the item are stored in 
a header record. As stock data accumulates (demand history, 
demand frequency, due-in quantities and others), it is added 
in the form of trailers. The access key to the MSIR is by 
Federal Item Identification Number (FIIN). 

The RSF contains randomly stored records of customers' 
requisitions (stored and accessed by document number) and of 
the supply action that has been taken by the stock point to 


Saeersty the requisitions. The RSF covers the most recent 
three months. 


The DHF contains the same kind of information as 
the RSF but covers the previous six months. Records that 
are deleted from the RSF are transferred to the DHF. 

The various operations that comprise the inventory 
Management subsystem are run on various frequencies from 
daily runs to weekly, monthly, quarterly and annual runs. 

The files are updated on a daily basis although certain up- 
dates occur less frequently. An important disadvantage in 
the design and in the way the system is run is the fact that 
many different programs (operations) update the same files. 
mapoemakes it very difficult to control the system, to ensure 
the correct sequence of file updates and, especially, to re- 
produce a previous state of the system files in case of a bad 
file entry or detection of a software error after the faulty 


program was used for a while. 
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4. UADPS and MRP 

From the discussion thus far, it should be clear 
that UADPS and the MRP applications have two different spon- 
sors. UADPS is run by NSC Oakland whereas NARF Alameda will 
develop and benefit from implementation of MRP. However, 
since vital information is available at NSC Oakland's DPD 
and since it will do the computerized inventory management of 
the inventory reserved for the NARF (in the RSS's), it is 
necessary to establish an appropriate interface between the 
Systems. 

The areas in which the UADPS and MRP systems need 
coordination and/or use the same data are: 

a. Inventory Status File 

MRP needs an inventory status file for determin- 

ing requirements and for other data elements on each item 
(such as lead time). This information is contained and up- 
dated in the MSIR. 

b. Bill of Materials 

Since maintenance work involves variable quanti- 

ties of components for doing the same work, the bill of 
material file of an MRP system has to be created and updated 
according to historical usage rates of components, when 
doing specific jobs. Computing usage rates involves identi- 
fication of the quantity of items that were repaired/produced 
Sia specific job order, and the components that were required 
Bemaccomplish the job. The first piece of data is available 
at the NARF whereas usage information is contained in the 


requisition files--both RSF and DHF. 
De 





Eee Roo otock Levels 
One of UADPS's functions 1s to set and update 
Stock levels for RSS. UADPS uses the historical demand as 
the basic data for setting those levels. It will be necessary 
to override the "'regular'' level settings by the requirements 
generated by MRP. 
These problems will be further addressed in the 


mext Chapter. 


C. EVALUATION AND CONCLUSIONS 

The Area Support Concept employed in support of NARF 
Alameda provides a significant advantage because of the cen- 
tralized management, stocking and procurement of supplies 
("economics of scale"). However, the common method applied 
to forecast demand may have an adverse effect on the effec- 
tiveness of supporting the NARF. The VOSL model assumes that 
demand in the future will behave the same as in the past but 
that may not be the case for the NARF because its material 
mequirements are driven by a production schedule which varies 
from one quarter to another. This problem can best be solved 
by employing the MRP model. 

The NIF store's inventory is and will continue to be 
Managed by a totally different system. The fact that the 
items carried in the NIF stores are fast moving, low cost 
mems seems to suggest their exclusion from the MRP system 
at least at the beginning. Also, the fact that their demand 


1s more stable justifies the use of a conventional model. 
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However, the time may come when the MRP system will be suffi- 
ciently reliable, when it may be more cost effective to have 
only one system for managing the NARF's material requirements. 
Including this inventory in the MRP system will require adding 
these items to the BOM file. 

seco ADP, it seems that NSCO's DPD may not be the activity 
mo run the MRP application. The out-dated equipment and the 
large variety of applications that are presently run seem to 
be sufficiently complicated to manage so that perhaps the NARF 
Should run the MRP system and provide the end results--namely, 
the material requirements and RSS stock levels, to NSCO's DPD. 
However, possible incompatibility of the Burroughs equipment 
at NSC with the NARF system may require appropriate transfor- 
mations of data to allow use of information maintained by 
NSCO (MSIR information and recognition data) in the NARF 


system. 
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IV. THE TEMPORARY MRP APPLICATION? 


When the idea to implement MRP at NARF Alameda was 
proposed, it seemed that before doing the full-detail design 
of the application it would be appropriate to carry out an 
experiment in which the MRP technique would illustrate the 
extent to which it could actually forecast the NARF's mater- 
meperequirements. But, as people got more involved in the 
supyect and obtained a better understanding of the work 
memonved, the 500 Department (the department in charge of 
this application) decided to redefine the objective to design 
the implementation of a simple MRP system that would take a 
Short time to implement, would be capable of demonstrating 
memtechinique for the purpose of comparison with the present 
System and would provide operational generation of NARF's 
material requirements until ASKARS and NISTARS are installed. 

Mmemvidc Cealized that there 1S a trade-off between sim- 
mmmeity, required effort and the length of the implementation 
period, and the quality of the results. Unfortunately, the 
NARF's regular personnel had to carry out the project with 
almost no additional people (their mission does not include 
software development!); the short time available made all 


Other alternatives infeasible. It is believed, however, 


lRased on personal interviews and discussions with 
LCDR W. P. Benefiel, from NARF Alameda. 
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that even this "low quality" product will produce a supply 
effectiveness better than that of the present system. 

This chapter describes the "'temporary" MRP application, 
the functions it performs, the data-base and software modules, 
the creation of the initial data-base and the interface to 


UADPS and NSC Oakland. 


eer ol EM OVERVIEW 

The temporary MRP application was developed and is run 
on the ADP system of the production planning and control 
department (500) at NARF Alameda. The system consists of 
a PDP 11/70 CPU with an IAS (Interactive Application System) 
general purpose operating system, 512 KB memory, 2 RPO06 300 
MB disk drives, 1 RS0O4 swapping disk, 2 TE16 tape drives, 
Mere line printer, 1 CRU card reader, 28 hard wired termin- 
als and some other "dial-up" terminals. This system is used 
to run several local NARF applications and can easily handle 
the MRP application. 

The major objective of implementing the temporary MRP 
System is to generate a forecast of the NARF's quarterly 
material requirements. These requirements are to be used 
as stock levels for the RSS. 

secondary objectives are to provide the NARF's material 
planners with accurate data that will Mesist them in doing 


Meir jOb, especially wnen ordering materials for unscheduled 


J0bs. The system is also to provide some exception reports 
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on consumption of materials to allow analysis of these jobs 
and the reason for the exceptional consumption. 

The system produces three major outputs: 

meeraterial Requirements 

These are only recommendations. They are checked 
and updated by the material planners if they do not agree 
with the systems recommendations. 

geeeanswers to Queries 

The system provides a set of queries on the BOM file 
meee pross requirements forecast. This information is 
used routinely by the material planners. 

Seeeeciil of Material Listing 

The listing is designed to provide the same basic 
information as the queries but requires the material planner 
to do the material requirements computation manually. The 
report is used as a back-up to the communications network 
and also for those material planners that do not have a 
berminal. 

The inputs to the system consist of requisitioning data 
from UADPS and induction data (quantities of items repaired) 
from NARDAC (Navy Regional Data Automation Center) that are 
used to update the BOM file and the workload schedule from 
ASO which is later used to translate the schedule into re- 
quirements. Another input is the information that relates 
IIC's (Item Identification Codes) to FIC's (Family Identi- 
fication Codes) which is required for translation of the 


Workload schedule--which is by FIC's--into a schedule 
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meeepc'’s. the inputs to the system are all external data 
Mmeerough it 1S Originated by or refers to the NARF. 

A major element that is missing in this MRP application 
is the inventory status file which has to be used for deter- 
mination of net requirements. The reason for that is that 
this application is used only to determine gross requirements 
Memeiteare needed as RSS stock levels. Therefore the computa- 
tion Of net requirements does not have to take place in this 
estem but rather in UADPS-SP. 

The environment in which MRP is run includes both time- 
meanang and batch processing. The requirements generation 
1s run on a quarterly basis. The run includes first an 
update of the files and later the generation of the outputs. 
This fact raises some questions about the need for on-line 
inquiries. But it turns out that, since the equipment was 
already there and was underutilized, it would be nice to 
meavide this service. 

Figure 5 describes the information network and the 


Operation of the MRP application. 


B. MRP DATA-BASE 
The data-base for the MRP application consists of three 
master files and two index files: 
1. The bill of materials file (BOM) (OSI19.DAT). 
2. The workload schedule file (OSI20. DAT). 


3. The MRP forecast file (OSI21.DAT). 
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Fipure 5: MRP information network diagram- 





4. The "BOM" index (OSI18.DAT). 


5S. Index to MRP forecast. 


The BOM file contains information about items required 
momrepair end-items. The file is a direct access file 
Maecess key is the IIC of the end-item) and contains one 
header record and several data records for each end-item 
(1iC). Both header and data records have fixed lengths. 
The header contains information about the end-item and 
summary data about the consumable items required for its 
@emair, total cost of consumables for repair of one [IC 
and the total number of the end-items that were inducted 
mi the past. 

The data record (one for.each consumable per end-item) 
contains the information as described in Table I. 


Figure 6 describes the header layout. 





me | 9 | FIC NSN COG | Total Cost |IIC Induction Qty 
ma) 5 | 6-9 | 10-22 |23-24 25-28 ay 


PIguucmo: ws bOM header-record layout 


Access to the file is based on a pointer to the begin- 
ning of the header, read from the BOM index file. The header 
1s used, and then (data) records are read sequentially. The 
First character is checked and if it is other than "1" it 


is assumed that the end of the IIC has been reached. 
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Columns 


B/-38 


39-40 
41-44 
435-48 
49-52 
B3- 56 
57-60 


; 61-64 


65-68 
69-72 
73-76 


TABLE I 


The Data Record 





Euler 
NSN 
COG 
U/I 


Planner & 
Estimator Code 


Sty (total) 


Unit price 


# of reqn's 
Qty per unit* 


yt of Qty per 
bad t* 


Essentiality* 


fremlacement factor* 
ery (err 1) 

# of reqns (Qtr 1) 
Qty (Qtr 2) 

¢# of reqns (Qtr 2) 
Qty (Qtr 3) 

* Of Tegn’s (Qtr 3) 


Qty (Qtr 4) 
# of reqns (Qtr 4) 


Char . 
Char. 
Char. 
Ghia. 


Char. 


Integer 


| Real 


inte .c 1 
Ineeger 
Char: 


Char. 

Real 

In Gegiet 
Tip ele ele3g 
Piece Jen 
Pee crc 
ieee gem 
hiteger 
Ditte oer 
pace cer 


Decimal Digit 1 


Required for Qty in 
header 


Whose total Qty is 
ieee b= 24. 


Max. Qty per 1 end 
item 


inmease 1t differs 
meometnhac in L/>18 


KE! or NEO! 


Pree Pe ey EO eet EO me ee ee ee 


*The data is extracted from the Weapons Systems File (WSF) 
maintained by ASO. 
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The information for each IIC contains data from the most 
recent four quarters. The totals are kept, and an average 
(total quantity/quantity inducted) is computed in specific 
application programs. 

The workload schedule file is a sequential fixed length 
record file, created especially for the MRP application. 

It is created by typing in (using an interactive data entry 
program) the workload schedule received from ASO. The 
memedule is by FIC (Family Identification Code), as opposed 
mo the BOM file which is by IIC. Figure 7 describes the 


layout of a workload schedule record. 


FIC | NSN of FIC ] Workload Qty | Standard Responsible Program 
Scheduled Repair Hours Shop 


ZU ee = ZONA) 41 





Figure 7: Workload schedule record layout 


As seen from Figure 7, the file also contains information 
that is not necessary for MRP--the standard hours for repair- 
ing the scheduled quantity. Before MRP was initiated, there 
was no other file that contained the production schedule and 
repair standard hours and because it was very useful (for 
Other functioners in the NARF) to have them, they were added 
to the records. 

The MRP forecast file contains the consumable NIIN 


forecast for each end item (IIC). These, in fact, are the 
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mee@sos requirements before they are summed to give one quantity 
for each NIIN. This file is used for two main purposes: 

1. Provide data for the material planners for planning 
purposes (answers to queries). 

2. Record changes made by the material planners to the 
SrOss requirements generated by MRP. Those gross require- 
ments are subject to inspection, changes, deletions and 
additions made by the material planners, and this file con- 


tains the last (best) version of the requirements forecast. 


The file is a direct access file and consists of fixed 
length records; each record representing a consumable NIIN 
required for a FIC/IIC. The data is grouped in a hierarchical 
Order: the highest level is a FIC, then IIC, and then a con- 
sumable NIIN. All data for one FIC is co-located and sub- 
divided into IIC's that comprise that FIC. Within an IIC 
are all consumable NIIN's required for the repair of the IIC. 

Figure 8 describes schematically the structure of the 
file. Figure 9 describes the record layout of the MRP fore- 
Bast file. 

The BOM Index file is, as its name specifies, the index 
Bo the bill of materials file, and in addition, it also 
contains the information that is used as the "translation 
meee Of the composition of each FIC by IIC's. This is 
achieved by keeping the total quantity inducted by FIC and 
the specific [IC quantities that een ise Phiae aqitianed ty. 
Dividing the IIC quantity by the total (FIC) quantity gives 


the relative frequency of the IIC and allows for the 
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Figure 8: 


« end ee 
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Figure 9; 


Schematic Structure of MRP Forecast File. 
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MRP Forecast File Record Layout. 
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subsequent translation of the workload schedule from a FIC 
schedule to an IIC schedule. 

This index file is used by various application programs 
to access the BOM file and its small size allows the whole 
file to be loaded into memory when needed. 

The file contains five different types of records. A 
Type 1 record contains two fields: FIC and the starting 
location of IIC location records within this file. There 
memcaesingle record per FIC and each contains a pointer to 
the location of the corresponding IIC's. 

The Type 1 records are delimited by a Type 2 record 
maren simply contains the four characters "END*". 

Petlowing the Type 2 record is a group of Type 3 records 
=-One record per FIC, each record containing "@e@e"' in the 
first four characters of the record (an identifier) and then 
the FIC quantity of total inductions and the FIC itself. 
Memonis the data used for the translation of FIC to IIC's 
and could, in fact, have been stored in the Type 1 records. 

Type 4 records contain the actual pointers to IIC loca- 
tions in the BOM file. Each record contains the IIC, IIC 
induction quantity (for translation), starting BOM location 
and ending BOM location for this IIC. The Type 4 records 
mee orouped so that all IJIC's belonging to one FIC are 
Begether, and the starting location of this group is being 
pointed at by a Type 1 record. 

A Type 5 record contains "@@@@"' and '0000"' and marks 


the end of the file. 
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The Index to the MRP Forecast file is a regular index 
mabe aliowing access to the master file by different keys: 


mie, FIC or NSN. 


C. SOFTWARE 
The temporary MRP application consists of the following 
modules: 
1. File maintenance 
meoueries 


3. Requirements generation module. 


Pile maintenance is the set of application and utility 
programs that are used to update the BOM file. As described 
in the previous section, there is no update of the production 
memedule file. 

The principle behind updating the BOM file is to advance 
Mae intormation regarding the second, third and fourth quar- 
Bers by one quarter forward (thereby deleting the "oldest" 
quarter), and then insert the information regarding the past 
meemeecer Into the fourth quarter's location. The file that 
contains the BOM information from the past quarter is created 
independently and is used later as one of the inputs to the 
program that creates the new generation of the BOM file. The 
Same process was utilized in creating the initial BOM file. 
Mumemchat 15 necessary is to stop after creating the file with 
Biesmost recent data (on the first run, it is the only data} 


and use the output as "the" BOM file. 
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The steps that comprise the file maintenance process 
are as follows: 

1. Create (by a simple data entry program) a direct 
access file of all customer orders that have been used 
g@uring the last quarter. 

2. Using this file as a table, extract from the Demand 
History File all records that contain customer orders that 
are in the table. (Note: The customer order contains the 
mic.) 

>. oort these records, which are in fact consumption 
mata, by IIC. 

meeconstruct the "induction data" file containing for 
each JIC the total quantity inducted during the last quarter. 
Bort the output by IIC. 

5. Use the induction data and the consumption data 
(both sorted by JIC) to create the one quarter BOM file. 

The same information is used to update the FIC to IIC "trans- 


lation table" that is contained in the BOM file. 


Figure 10 describes the file maintenance rum. 

imecueries are programs designed to assist the material 
Menners in their work. There are dynamic queries in which 
mie planner can change the information in the file he is 
Suerying as opposed to "static" queries in which the infor- 
mation is only presented. 

The "static" queries include the following: - 


I. Inquire BOM by FIC. This inquiry displays all data 
(with appropriate headings) about the FIC. 
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Figure 10: BOM file maintenance run. 
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meeingquire BOM by [IC. 


Seeinquire MRP forecast by the following pairs of 
parameters: 


(a) $ value/shop 
Soees Value/IIc 
wey > value/FIC. 


The $ value refers to the value of the consumable items. 
Such a query will list all consumable forecasts for end 
items/shops whose $ value is greater than the threshold 
@eecitied in the query. The information about each end item 
meepresented separately. 


4. Inquiry by a variable threshold of $ value of consum- 
ables value. 


Here the planner specifies a value threshold and gets, in 
return, all NSN's whose value is greater than the threshold 
specified. This allows the planner to concentrate on the 
most expensive items first, and then on the other items. 

Siem dynamic’ Or interactive inquiries refer to the MRP 
BOrecast file and are intended to use the material planner's 
knowledge in order to get a "better" forecast. The planner 
miguires the file by NSN (of consumables) and thereby gets 
Mequential access to all [IC's that include that consumable. 
After having the information displayed, the planner can (by 
using appropriate codes) make additions, deletions or changes 
in the forecast of the requirements for that specific IIC. 

aiee Requirements Generation is the heart of the appli- 
Cation and concludes the whole process. This phase has two 


Separate steps: 
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1. Creation of the MRP forecast. 


Meme reation of the transactions for the RSS stock 
GBepienishment. 


The MRP forecast is generated by computing an average 
meg@uarement for each IIC (total consumption during four 
quarters divided by total end-item inductions) and then 
muitiplying it by the quantity of that IIC scheduled for 
Pauction during the coming quarter. The IIC induction 
quantity is computed from the FIC schedule by multiplying 
the FIC quantity by the relative frequencies of the IIC's 
Composing the FIC. This forecast is used to load the file 
which will be used by the material planners. 

After the material planners have finished their changes, 
Meemnext Step 1S to sort the requirements by NSN (of consum- 
ables), sum them for each NSN and write a transaction to an 
mtpmc £Lile; this file contains the NSN and the total 
Siantity. This quantity will have to be in the RSS at the 
beginning of the quarter (or shortly after it) to ensure 
smooth operation of the NARF according to the production 


schedule. 


i INPUT, OUTPUTS AND PROCESSING 

The inputs to the MRP application are mainly the outputs 
of the UADPS-SP. These include the demand history file (DHF) 
from which the NARF's requisitions are extracted, to be used 
later as consumption data for updating the BOM file, and also 


the MSIR, from which general information such as nomenclatures, 
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units of issue, unit price and quantity-on-hand (at the RSS) 
are extracted. 

Another input is the committed workload file (CWF) which 
Bontaims induction quantities. This file is maintained by 
NARDAC for the independent production control application. 
The workload schedule file that was described in the data- 
Base section is, of course, another important input to the 
System. 

The last input is the set of valid customer orders (job 
numbers) which are entered through an interactive data-entry 
program and are used as a table for extracting relevant 
records from the DHF. 

All inputs described above, except the MSIR, are origin- 
ated at the NARF, although part of them (DHF, CWF) finally 
arrive at the MRP application as external inputs. This is 
an important factor because it leaves very little control 
(frequency, data integrity) that can be imposed by the MRP 
application. 

The outputs from the MRP application were also described 
earlier. They include essentially the transactions for level 
setting of RSS stock, answers to queries by the material 
planners and various reports which are generated during the 
process of file maintenance and requirements generation. In 
a well developed system, these reports would have been outputs 
Memerier applications, but since these do not exist at the 
NARF, this was an opportunity to produce these products. 


Examples of these products are a list of customer orders 
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(instead of a production schedule), summary induction infor- 
mation by JIC, and BOM listings for general use by material 
planners (as back-up to inquiries). 

The MRP application involves two modes of processing. 
The first is the process of file maintenance and require- 
ments generation which is run once per quarter. The other 
is the inquiry system, in which files and programs are loaded 
permanently and used by the material planners. 

The file maintenance involves a sequence of events that 
determines the schedule of the whole process. The first 
constraint is that the BOM cannot be updated as long as 
customer orders are still active because the consumption is 
merecomplete yet. Customer orders are closed at the end of 
Bieesecond month of the quarter following the quarter for 
which they were opened; this then is the earliest time for 
the beginning of the process. 

Peesecond constraint is imposed by the determination of 
the production schedule. This is done in a conference that 
takes place during the first week of the third month of each 
quarter, and during the conference the schedule for the 
Coming quarter is determined and a tentative schedule is 
prepared for the following quarter. 

Consequently, the processing goes as follows: The old 
BOM and the tentative production schedule are used to pre- 
Pare the background information for the conference (identify 
memeical items required to carry out the schedule). Then, 


during the first week of the third month, the file maintenance 
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run is performed making the BOM ready for generation of the 
eross requirements. The requirements generation program is 
run in the second week of the third month using the final 
production schedule that was determined in the conference. 
The MRP forecast is then loaded for analysis by the material 
planners who have another week to make their changes in the 
material forecast. At the end of the third week the final 
run is made and the transactions are generated and submitted 
to NSC Oakland. This leaves at least seven days for NSC 
Oakland to process the transactions and to position the 


materials in the RSS. 


E. EVALUATION OF THE TEMPORARY MRP SYSTEM 

A review of the temporary MRP application reveals a number 
Ot problems. The first problem relates to the production 
Schedule. Implementation of MRP requires the existence of 
Such a schedule. The NARF does not have an automated produc- 
tion schedule, and the file that is used here is created 
especially for the MRP run. Consequently, the file is used 
only for MRP and lacks feedback and updates as the schedule 
is carried out. Therefore, the possibility of updating the 
material requirements during the quarter does not exist. 

The file maintenance software also involves some problems. 
The software was designed with simplicity as a goal, thus 
leaving some areas uncovered. One of these is the update of 
the BOM file as new jobs appear. Since the only basis for 


updating the BOM file is actual jobs that have been completed 
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metne past quarter, there iS no way to enter information or 
estimates about jobs that are scheduled for the first time. 
whais means that the system will not be able to forecast re- 
quirements for the whole production schedule, and there will 
always be some customer orders that will not have materials 
prepared. This problem is partially solved by allowing 
material planners to change forecasts, but they do not have 
the possibility of inserting a whole new item. 

Validity checks on input are another problem that is 
treated only partially. Although most of the inputs come 
from other systems, there still should be some checks, 
especially on the reasonableness of material consumption. 

An analysis of the NARF's requisitions during the period of 
April 1978 until March 1980 revealed many requisitions for 
Wery large quantities, presumably resulting from combined 
mea@uisitions for more than one customer order, but reported 
On only one order. If such quantities are not extracted 
(by some kind of inspection), they may ruin the averages in 
the BOM file and consequently the whole forecast. 

The way the system was developed may introduce a prob- 
lem after the system becomes operational. The system was 
Mesioned and implemented by a project officer and two pro- 
Srammers that were especially hired for this mission. The 
mame@lvement Of other people, and especially users, in the 
NARF's 500 Department was minimal and this means that a 
special effort will be required to train the users, acquaint 


them with the new tool, and make them efficiently utilize 
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the system. The lack of good documentation (because tho 
software was written by people that were hired for a very 


miert period of time) will make that job very difficult. 
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Vee nee hOmOsED MRP SYSTEM 


The proposed MRP system is designed to meet the same 
objectives as the temporary system, i.e., forecast of NARF's 
material requirements, maintain and update the required data- 
base, and provide the appropriate interface to the supply- 
Support system. However, the introduction of ASKARS, as well 
as the problems that have been identified in the temporary 
System, require and provide the opportunity to introduce 
some improvements. And that is what the proposed system is 
intended to do. 

The intent of this chapter is to provide a functional 
Meoten Of the proposed system. It should serve as the basis 
for detailed design and implementation by NARF Alameda people 
after ASKARS becomes operational. 

The implementation of ASKARS raises the following factors, 
which will become important to the design: 

1. New ADP equipment will be installed. In addition, 
there will be new software and application programs; this 
requires compatibility between the system on which MRP will 
be run and ASKARS. A logical solution 1s to run MRP on the 
ASKARS ADP equipment. 

2. The available time for design and implementation of 
the proposed system is long enough to prevent short-cuts 


because of time pressures. 


76 





- 


meine implementation of ASKARS requires professional 
mee people. 

4. ASKARS' software, and especially the order processing 
module [22: Enclosure (1), Section 5], has many similarities 
to MRP. The use of the same or a slightly changed approach 
in the design of the MRP system will increase the understand- 
ing of the MRP system and facilitate its implementation and 
maintenance. 

Peimajyor component of the proposed system is the algorithm 
@emeecmeration of the gross requirements. The fact that NARF 
Alameda performs mainly maintenance instead of production 
results in an uncertainty about the BOM information. This 
has been treated only in a minor way in the temporary system. 
Therefore, a considerable effort is devoted here to develop 
Meeetcer and more accurate algorithm to handle this uncer- 
eainty. 

Another important area that this system considers is the 
production schedule and the human resources (professions and 
Standard hours) that are required to carry out the schedule. 
memee a production schedule file is not in existence at 
present, a simple application is proposed below. It will 
Meemsty the MRP requirements as well as the basic needs of 
mie production and control people. 

Production planning and control was also a major factor 
in the design of the BOM data structure. It provides the 


basis for inclusion of other resources in the BOM file. 
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mois May contribute further to a better and accomplishable 
Smoduction schedule. This will not be developed here in 
detail, but will be outlined for further development in the 


future. 


A. PRM-MRP: PROBABILISTIC REPLACEMENT MODEL FOR MRP 
This section is devoted to the development of the proposed 
model for material requirements planning in a maintenance 
oriented facility. 
1. The Demand Distribution 

The demand for an item in a maintenance oriented 
environment is determined by the following three factors:- 

a. The Production Schedule 

It determines the end items that will be reworked 

and thereby determines the set of consumable items that are 
candidates for consumption. The candidates are the compon- 
ents that make up the scheduled end-items. 

b. The Replacement Factors 

The replacement factor of a consumable item 

that comprises a specific end-item corresponds to the pro- 
portion of the installed quantity of that consumable item 
in one end-item that is expected to be replaced/consumed 
maetne course of reworking the end-item. The replacement 
memror, P, takes on values such that 0<P<I1 where P=l1 
represents consumables that are always replaced during repair 
of the end-item and P=0 represents components that are never 


replaced. The replacement factor is affected by maintenance 
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Memgetes, experience of the people that do the maintenance, 
and by the nature of the item and the environment in which 
merits used. 


c. The Demand Distribution for the Item 
Being Replaced 


iene Ny» Noo +++, DL be the installed quantities 

of a consumable item in m different end items IIC,, TIC., 

i TIC, respectively. Let Pi» Po; vee Po be the corre- 
sponding replacement factors of that consumable item and let 
Q1> Qor eee, oe be the scheduled quantities per quarter for 
maenend items. Let Xx, be a random variable representing the 
demand for the consumable item during the quarter for the 
scheduled repair of TIC,. Then, Xs has a Binomial distribu- 
tion, namely 

new X We QteX. 
a a 1 _ Joe —_ 

b(X;5n.Q,,P;) = ( fe vee Cl P;) Semele lene s,s 
The mean of the distribution is n,Q.P; and the variance is 
n,Q.P,(1-P,). i278 ,09 1. 

Each X; is an independent random variable because 
the demand for an item by an IIC is independent of the demand 
for that item by another IIC. 

Consider now the total demand for an item during 
a quarter. Let it be the random variable X. It follows 
that 
1, t+ Xo t+ +s + Xe 


The mean of X (or expected value of X) is 
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Mh 
Mm 11a M2922 te * MQ Ba Rahy 127240. 


mmatlarily, since X1sXo5-+- 5X, are independent variables, the 


Mariance of X, Var(X),1s 


Var (X) nj QP (1-P,) +n,Q,P,(1-P,) +... +n,Q PP (C1-P J 


m 
= Me 3? 


The probability distribution of X can be approxi- 
mated (with continuity correction) by the Normal distribution. 
fine Basic Model 

Planning Horizon--Repair schedules are developed on a quar- 
Memiy basis at the NARF. Additionally, the inventories of 
consumable repair parts are funded either from the Navy Stock 
Fund (NSF) if provided and managed by a NSC or by the Navy 
Industrial Fund (NIF) if purchased and managed by the NARF. 
Both funds serve as revolving funds which provide a fixed 
amount of money for a given quarter to buy inventories. 
Customers are billed for items used and submit payments to 
mnese funds. The money collected is returned to the NSC or 
Mie eNARF at the beginning of the next quarter. Adjustments 
in the amount of money in either fund is made quarterly or 
less frequently depending on the variation in the production 
Schedule. 

ccwsceGmmeuic Lepair schedule and the nature of the 
NSF and the NIF, demand for repair parts appears to be inde- 


pendent from one quarter to the next. Therefore, the model 
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to be presented below will have a planning horizon of one 
quarter in length and will be what is known in inventory 


theory as a"'single period" model [14: Chapter 6]. 


Meective--In providing an inventory of repair parts the 
Hogical objective is to strive for a maximum availability of 
each item. I[f it is known that an item is replaced 100% of 
Mice time during overhaul of an end item, then it is logical 

to stock for that 100% level. The MRP approach will determine 
the total quantity of such an item easily. 

If, however, an item is replaced less than 100% of the 
meme, chen stocking that item to the 100% level is going to be 
wasteful unless future quarters' production schedules are able 
to absorb any surplus. A surplus at the end of a quarter in 
absence of knowledge of future schedules results in NSF or NIF 
money being tied up which could have been used to buy more of 
some other item either in the upcoming or in the past quarter. 

Thus, a balance needs to be sought between the chance 
of a surplus and the chance of a deficit for the items not 
replaced 100% of the time such that the remaining funds in the 
NSF or NIF (after the "100% items’ are purchased) are used 


erticiently. 


M@eyective Function--The balance being sought above will be 
determined by developing an objective function which describes 
Hhe expected costs for all the items not replaced at the 100% 
Tevel as a function of the amount of each item to be placed in 
the RSS or NIF stores at the beginning of the quarter. The 


EOllowing costs are assumed to be appropriate for this function. 
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a. Processing Costs 
A special processing cost per unit, Cy which is 
different from the procurement cost, is incurred to establish 
memetem in the RSS or NIF's stores. If the quantity of an 
item going into a store is denoted by y then the total pro- 


cessing cost for that item will be represented by the product: 


oe 
wee HOlding Costs 
The space required to store an item being demanded 
during the quarter must be large enough to hold all y units of 
Mae item. <A unit cost, C> 1s assumed to be incurred regard- 


Mess Of how long a unit is in the store during the quarter. 
Mie total holding cost will therefore be: 
CLY: 
Mer enalty Costs 

Two forms of penalty costs should be considered. 
The first is a shortage cost for being out of stock at some 
time before the end of the quarter; the second is a surplus 
cost for having undemanded units of an item still in stock at 
the end of a quarter. 

In the case of a shortage, a unit must be obtained 
from outside the store. In the case of the RSS, this unit 
Might be available at the NSC or it might have to be obtained 
Somewhere else in the supply system. In the case of a NIF 
store it would probably have to be obtained from the appropriate 
DLA or GSA source. Concentrating on the RSS from now on, we 


assume a cost of 7, per unit requisitioned from the NSC and a 
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@ost of ™, per unit requisitioned from outside the NSC. 
Mmese costs should reflect the time delays resulting from 
Maving to go outside the RSS. It is reasonable to assume 
that T) << > 

If demand X for an item exceeds y, the amount in 


the RSS, then the shortage cost will be: 
Tl [X-y] ’ 
if X is not so large that the stock w at the NSC is also 


Memausced (that is, X < y + w). If X is so large that we 


mest gO to the outside, then the cost will be: 
TW + Tole. y= WI. 


mMmeicmcadsc Olea surplus, the unit cost for having 
@esurplus is assumed to be kC where C is the unit purchase 
cost and k is a factor which may be greater than 1.0. The 


cost of a quarter's surplus can be then written as 
kC{y -X] , 


mma applies only if X < y. 
d. Expected Total Costs 
If we let p(x) represent the binomial probability 
that X units are demanded during the quarter for a given item, 


the expected total cost for the quarter can be written as: 
i 
EC(y) = (C,+C, ly + &£ kC{ly - X]p(x) 
P 7 X=0 


an 1 
mn Key +171 IX ~ y]p (x) 


*F . {w4w + t9[X-y-wl] }p(x 
yaya TY * T2EX- ¥ > w)IPCO) 
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If the demand is sufficiently large that demand can be 


assumed to be Normal then 
y 
EC(y) = [C., + Cily eee (ye Xo £ (x idx 
oO 


aay 
hy m1 [X See Ox x (2) 
y 


+f. it 4W eee ow) tf (x)dx, 
yaw 


where £(x) denotes the density function for the associated 


Normal distribution. 


mea Order Quantity--The basic model seeks to determine a 


Seeeeror y > 0 which minimizes EC(y) in either the discrete 

meteor equation (1) or the continuous form of equation (2). 
fmiewcaiculus can be applied to equation (2) to get 

Mecamal y. Taking the first derivative of EC(y) with respect 


to y and setting it equal to zero results in 


_ mec ©, * KC Cee) 
E (Cy } oe Cs) 
T) + kC 
where 
F(y) = fot (x) dx 


and 
F(y + w) = Lf (x) dx. 
In the discrete case we want the largest value of y for which 
cat eel }P(y + w) 


TT TT 
eee ee e 
Ty + kC 
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where 


p(x) 
y 


me) = 


os 
lm 8 


and 


mit +w) = 2 p(x) 
X=y+w 


Thais resuits from the analysis of finite differences in which 


we seek the largest value of y for which 


ety - EG{y-1) < 0. 


In the event that the NSC has a large stock outside 


the RSS we can assume w > ~ and equations (3) and (4) reduce 


to 
C+ CL + kC 
2. 
F(y) eee ae (5) 
Ty eke 
C+ Cy + kC 
Dp a 
apy) > (6 ) 
un + kC 


3. Extensions of the Basic Model 
The basic model described above did not consider 
Situations where two or more end items are demanding units of 
the same repair part and where a budget constraint limits the 
amount of units which can be purchased for each of two or more 


mepair parts. 


Two End-Items Demanding Pilcmoome hepa lier ane]-10 SeUay tn is 


Case, let Xy and X, 


demanded by end items Nos. 1 and 2, respectively. The total 


be the units of a certain repair part 
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demand X for the repair part is then the sum of X, and X 


1 2? 


namely, 


ie sumplus cost term of the expected cost for a 


quarter is the same form as above, namely, 


eyo | P(X) 
O 


os 
WM s< 


OT 


Mic [y - X]£(x)dx ; 
O 


except that now p(x) and f(x) are the probability and density 
function associated with a total demand of X. Since X is the 
sum of X) and X, and since Xy and X, are independent random 
memiables we have a density function for X which is approx- 
imately Normal as discussed earlier. 

The shortage cost term is more difficult to develop. 
Let us assume that a quarter has a length of T time units 
and that the supply y of an item is exhausted at t time units 
meter the start of the quarter. It follows that if t < T 
then a shortage will occur before the quarter ends. Let us 
also assume that the two end items consume at rates Ty and 
r5 where 


Xy X2 
pe ge?) *2 °° T 


From knowledge of Ty) and r, we can determine t since 


ey ro)t = y 
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Hus , 


pve = WY! CC, 


r,*T, 4X, +4, 


The shortage cost function for end item No. 1 will be 


then 
xX 


X] i aaa 
my [Xp -ryt) = my QE AH = a [XI 
iF 2 i 2 
where 74,15 the shortage cost associated with getting a unit 
Menthe repair part from the NSC for repair of end item No. l, 
Meethe supply at the NSC can meet the total demand. Similarly, 


for end item No. 2, 


T1729 


ig > ~ 1 2t) = Se olay) 


The sum of these shortage costs is 


pe 1242 X= y] 
a 2 


and the expected costs of shortage can be approximated by 


. Ty,Hy * Ty2H2 


o> -y | Pex 
rap EK v1 Ed 


if the NSC has a very large back-up stock. The terms y, and 
Mo correspond to the mean demand for the individual end items 
Mer the given repair part [28]. 

The expected costs for one repair part used by two 


end items can be written as 
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Y 
EC(y) = Sec + eae vas KEI OS abe 


Z fm 1X - y] £(x)dx (7) 
where 
Meee ite T1222 
1 HW, + Uy (8 ) 
The optimal value of y can be determined from equation (5) 
it ™) is that given by equation (8) and F(y) uses the distri- 


bution of the random variable X where X = Xy + X,. 


More than Two End-Items Demanding the Same Repair Part 


Equations (7) and (5) are still applicable when we have 


nm end-items if we use 


X= X, +X, + +X, 
and 
ied he Tin'n 
: 
iu? agit My 


The model, and the problems associated with providing 
the data it requires, are further discussed in Appendix E. 
However, the discussion in the following sections assumes 


that the necessary data will be available. 
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B. SUPPORTING INFORMATION 
The basic principles of an MRP system and an example of 
a system that satisfies some of the NARF's needs has been 
described in previous chapters. Therefore, the material 
presented hereafter will not repeat all the details and will 
assume that they are clear. 
meaeoutputs, Inputs and Data-Base 
The outputs of the proposed MRP system are basically 
the same as those of the temporary system. The main differ- 
ence should be in the accuracy of the forecast that the system 
generates. 
ime system will produce the following outputs: 
1. Material requirements forecast. 


2. Answers to queries about the forecast and the BOM 
file. 


5. Transactions for RSS level setting. 


4. Transactions for updating the ASKARS order processing 
module. 


The additional transactions generated by the MRP 
System are designed to provide the input to ASKARS that will 
allow using its existing software for follow-up on the trans- 
actions submitted to NSCO from submission until the material 
is received and placed in the appropriate bins in ASKARS. 

The types of inputs to the system and the data-base 
are the same as in the temporary system. The structure of 
the files and the fields in the records are different but 
basically the same kind of inputs are used to maintain 


Similar files. However, there are two differences: 
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a. The input for maintaining a production schedule 
will be more involved but will upgrade the quality of the 
Meea-base. This subject is covered in detail in a special 
section on the production control subsystem. 

b. The material requirements forecast, which is an 
output of the system, will also be an input to another pro- 
Seam that will use the same information to generate the 
order processing transactions for ASKARS. 

fae Functions 
The MRP system will perform the following functions: 
meeeinput edit. 
Pee Query. 
@eeeRepOrt generation. 
feria le maintenance. 
EweRoo level setting. 
f. Generation of information for requisition follow-up. 
@. Analysis to identify exceptions (in material usage). 
3. Algorithms 
Bout alcorithms are needed for MRP. 


meeextract data from given files according to required 


fields/sequences. 


b. Sort files according to required fields/sequence. 
@eeiranslate FIC to IIC's and vice versa. 
d. Generate requirements for given quantities of IIC's. 
The first two algorithms are in fact utility programs 
that are usually provided with the operating system and can 


be used on any file. On the other hand, the translation 
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algorithm and the algorithm for generating the material 
requirements are specific to this application and will be 
developed later on. 
a> Environment 
The environment for running the MRP system includes 
both time-sharing and batch processing. Time sharing is 
required for the queries whereas all other runs are in batch. 
ASKARS' operating system requires and permits both environ- 
ments [22]. 
5. Information Network 
Running the MRP system involves the 500 Department 
at NARF Alameda which is responsible for the application and 
some external activities that provide inputs to the system 
or use the system's output. Among those are NSC Oakland, 
the production and supply departments at the NARF, the 
ASKARS system and ASO. Figure 11 depicts the information 


network for the proposed MRP system. 


C. MATERIAL REQUIREMENTS ALGORITHM 
The algorithm for determining material requirements for 
repair of end-items is the heart of the system and there- 
fore it will be described in full. 
The algorithm is expected to be called in two cases:- 
1. Queries. 


2. Generation of the quarterly material requirements 
bomecast. 


The two instances differ in that a query will usually 


involve a single (or a small number of) end items whereas 
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Figure 11: Proposed MRP System -- Information Network. (Frequency 
of runs and volumes of transactions are given 1n 
Appendix B.) 
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the second case involves the whole production schedule. 
This implies that the algorithm should provide a means for 
meine it for more than one end-item. 

Another requirement is to allow the user (especially in 
gueries) to provide either a FIC or an IIC and have the 
program do all additional work to get the end result. 

A calling sequence that will meet the requirements is 


memeeemRP(ID,T,Q,S,E) where:- 


Mmm= End-item identification code (input parameter). 
ims ivype of identification code (input parameter). 
ae LS ror 6LIC, 
ieee ec 6 6htOr 6€FIC. 
Q = End-item scheduled quantity (input parameter). 
S = Sequence code (input parameter). 
fil to specify first call. 


Bb. ‘2’ to specify that the subroutine was 
Smebed previously in this computation. 


emo tO Specity that there ane no more end-items. 


feo krror code (output parameter). 


Subroutine MRP will be called from other programs. The 
Mearameters will be either supplied explicitly by the user 
mri, 0} Or implied (S) by events (first item, EOF or special 
mie «Of Special importance is the sequence code that deter- 
mines what modules will be executed. This code is set to 
meeeby the calling program for the first end-item. Subse- 
quent calls will have the sequence code ''2'" and when there 


are no more items the calling program will issue a terminating 
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meee CALL MRP(9999,1,0,3,0) ) that will tell the algorithm 
to proceed to the next phase of summing up requirements. 

The MRP algorithm includes two phases of processing as 
Shown in the block diagram in Figure 12. In the first phase 
the end-items are specified by the caller and used as access 
keys to the BOM (directly when end-item is an IIC or indirectly 
mraetne FIC to [IC translation table when the ID is for a FIC. 
Then, the BOM information and Q are utilized to compute "raw" 
material requirements and to write records (one per NSN) to 
the raw materials file (an intermediate file). This phase 
ends when the subroutine accepts the terminating call (S=3). 
has Causes execution of Phase II which begins with sorting 
Siethe raw requirements by NSN, computing total requirements 
Semeconsumable, and writing the result to the final output. 

Customer orders that are in the production schedule and 
have been started previously require special processing during 
meoetevel setting. It is not of concern in queries since the 
material planner only wants to know the material requirements 
fOr a new job. 

Semi-finished jobs are processed by the Regenerative MRP 
model. The requirements for the rest of an unfinished job 
are determined by subtracting the actual consumption thus 
far On such a job from the material requirements for the 
whole job. The production schedule that is the input for 
RSS level setting will include uncompleted customer orders. 


However, the actual consumption on the customer order from 
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the previous quarter will be extracted from the DHF and RSF 
(by customer order) and this temporary file (Expended Mater- 
mals tile) will be another input to Phase II of the subroutine. 
This means that the Raw Material Requirements file and the 
Expended Materials file will be read in parallel (matching) 
and the gross requirements for-a consumable NSN will be 
derived by taking the difference between the total forecast 
Smeamtacy for that item (computed by the PRM-MRP computation) 
meom the Raw Material Requirements file and the total quantity 
Por that item in the Expended Materials file. Figure 13 

Shows the record layout for the Raw Material Requirements 
file. This file also contains the necessary information for 
mempucing the probability distribution function for the total 
mequirement. 

The final output from the MRP subroutine will be later 
formatted in the calling program (or by a different program) 
to either write the level setting transactions or to display 
mem on the terminal. 

Subroutine MRP involves some error checking and parameter 
validations. A list of the errors the program will look for 
iS given in Table II. The successful completion or the 
detection of an error will be reflected in the E parameter 
of the subroutine which, in fact, is a return code. A 
return code which is other than '0'' will cause the calling 
program to display an appropriate error message and, in the 
case of material forecast generation for RSS level setting, 


the exclusion of that end-item from the forecast. 
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TABLE [I 


PmGEonomnctunnec bY subroutine MRP 


Error Return ; Corresponding 





Code* Parameter peer aon 
00 == Successful call 
11 i) TIC/FIC does not exist 
ZA. T Invalid type (other than 
ee Oyen 
orl Q Invalid quantity (must be 


an integer) 


41 5 Invalid sequence code 
(other thane), 92 or 3) 


42 5 First call before a previous 
computation was completed | 
43 S Se Vawitneutea previous call] 











| 
| 
Ee S=1 
| 


44 5 S=3 and other parameters 
not as required 
49 Warning. S=3 without 


Sal On 5 = 2. 


* The return call is an output parameter and is checked by 
the calling program. 
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Quantity peacwonr  (— ) Quantity (Q) 


ZS 





Figure 13: Raw Material Requirement Record Layout. 


Figure 14 shows the detailed flow-chart of the subroutine. 

The subroutine will require approximately 150 lines of 
mete veol-language code. When executed, it requires on-line 
meeraee Lor the BOM file, the Inventory Status file (MSIR 
mxtract), the FIC to IIC translation table, and the Raw Material 
meaquirements file. In addition, memory is required for input 
and output buffers and for the table created by the subroutine 
Semeissuing calls by IIC when the original call is by FIC. 
These resource requirements add up to approximately 50K Bytes 


of memory and 100MB of on-line storage. 


oe THE PRODUCTION CONTROL SUBSYSTEM 

The existence of a production schedule is one of the MRP 
prerequisites. Since the present production and control 
System at NARF Alameda does not provide satisfactory and up 
Pomdate information, there is a need to develop the appro- 
priate software and maintain the required data base that 
will satisfy the proposed MRP application. 

The Production Control Subsystem (PCS) is designed to 
produce the following outputs: 


jmerroduction schedule listings. 
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Beeeeswers tO queries about the status of customer 
euaers. 


Seeenmput edit reports. 
4. Progress and exception reports. 

Production schedule listings will be produced in two 
different sequences. The first sequence will list all 
customer orders that exist in the data-base. This report 
will be used by the production planners in the 500 Department 
and the production department head (900 Department). The 
meport in the other sequence will be used by branch heads in 
the 900 Department and each report will contain only the 
customer orders with which the shop is involved. Both 
reports will contain the same information but in different 
memmences Of customer orders. 

The queries will provide essentially the same information 
@s the production schedule listings. However, the query will 
refer to one customer order only and will display the rele- 
mamenup to date information. The queries will be by customer 
meer, by FIC or by IIC. 

The intent of the input edit report is to give the status 
of the transactions that were submitted to the system. Trans- 
actions that contain errors will show up in the report with 
appropriate error codes specifying what the error was; for 
example, invalid record type, invalid dates or missing data 
cems. 

The progress and exception reports will resemble the 


meeduction schedule listings in format. The difference will 
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Senin the information printed in the reports. This informa- 
tion includes standard hours for completion of the whole job, 
number of hours expended in the job since the previous edi- 
tion, and exception messages for those customer orders in 
march progress was not satisfactory. 

Two generations of the Production Schedule file will be 
used to produce such reports. They will be one month (or 
two weeks) ee according to the frequency of printing of 
@ report. The progress in a job will be computed by subtract- 
ing total expended hours recorded in the previous generation 
of the file from hours expended in the same job until the 
present time. This progress will be analyzed to determine 
Semis Satisfactory. The criteria for classifying a 
customer order as an exception will have to be set up by the 
production control people. Some possible criteria are listed 
below: 


1. Expended hours exceed standard hours by more than 20 
percent. 


2. The proportion of expended hours relative to standard 
hours is less than 70 percent of the proportion of 
time that elapsed relative to the total duration 
meauired for completion of the job. 

3. More than 20 days have passed since the latest 
required finish date and the job has not been 
finished yet (or not reported as finished). 

This report will also be produced in two different 
sequences: a listing of all exceptional job orders and 
mmotner jlisting by shops/job orders. 


The inputs to the system will come from two sources: 


transactions reported by the production control department 
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@eaimputs that were generated by other applications. Among 
the last group are inputs about standard hours from the Master 
Data Record (MDR) file, expended labor hours from the Sorted 
mapere transaction (SLT) file and induction data from the 
Sorted WIP (work in process) History Activity file [23]. The 
transactionsthat will be written especially for the system 
are intended to maintain information about planned induction 
G@Uantities and scheduled dates of the different job orders. 
They will also allow changes in the status of job orders. 
The transactions will allow reporting on individual job 
@egers Or On a whole FIC. This last option is especially 
needed for reporting a new production schedule. A simple 
data entry program can simplify the process of reporting the 
meadiicactiOons mentioned above. Figure 15 depicts the layouts 
@ieaine different inputs that the system will process. The 
MOR data will be extracted directly by the PCS file mainten- 
ance module and therefore the standard hour information will 
mot show up in these layouts. The different transactions 
will be edited by an input edit program that will check the 
Metterent fields for validity. Other fields, like the job 
order and transaction code, will be examined later by the 
file maintenance program to make sure that when the code 
specifies an update, the job order already exists. 

To perform its functions, the system will maintain a 
PCS file that will store the information about the various 


job orders. The file will be a direct access-variable-length 
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Mecord tile. A logical record will consist of three basic 
structures: 
1. A header for each FIC/FY/Quarter. 


Peevobd Order trailers for jobs belonging to the above 
FIC/FY/Quarter. 


3. Shop trailers for shops participating in the above job 
order. 


Mach such record will store the information about a particular 
FIC which is scheduled for a specific quarter (i.e., if the 
file covers a period of one year, there may be 1 to 4 differ- 
ent records with the same FIC). The tree structure of a 
Mogical record is depicted in Figure 16. The file will be 
accessed by FIC/FY/Quarter. However, this index and the 
translation subroutines from FIC to IIC and vice versa and 
Brom 30b order to IIC will allow direct access to the file by 
merner 0b Order or IIC, fiscal year and quarter. Figure 17 
Mepicts the layout of each one of the PCS record components. 
The header information contains information about a FIC 
that is scheduled. Each job order trailer represents one of 
the specific job orders in which an IIC belonging to the FIC 
will be overhauled. The job order trailer contains summary 
data about the job order and allows access to its shop trail- 
ers which contain information (namely standard and expended 
hours) about each shop that participates in the job. 
Maeestatus of a FIC or a job order represents the situa- 
meron Of a group or a specific job respectively. The status 


Can be one of the following: 
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metre bo: PCS data structure. 
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blank - The job has not been started yet. 


vow ine jObD 1S in process (i.e., expended hours 
iiee DOsttive ) . 


Seu ine job has been cancelled. 


See ihe job has been finished. 


Since the FIC header represents a set of job orders, its status 
met retlect the status of its composite set of job orders. 
mne header status will be changed to "W" when the first job 
has been started. Similarly, it will be "F" only after the 
last job has been finished. The status can be changed to ''C" 
maly Dy a status reporting transaction (see Figure 15). Con- 
Bequently, the "'date of status'' field will represent the date 
of the last change in status. 

The production control subsystem software will include the 
fTOollowing modules: 

imeeeenput Edit 

This module will validate individual data fields and 

Bill print out records that contain erroneous data. 

Zeer le Maintenance 

This involves performing further validity checks on 

good records from the previous step and subsequently updating 
BE the PCS file. The FIC transactions will be the first to 
update the file. These transactions will cause the creation 
of new FIC headers, and then job order trailers with predicted 
quantities (based on relative frequencies of IIC's) and shop 
Mraiiers with standard hours from the MDR. Subsequently, 
Other transactions will update or add information to that 
Which was generated by the FIC transaction. 
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Peeeeouecries. 
meeeecporc Generators. 
meocuction schedule listings and exception reports. 

Figure 18 describes the information network and the data 
flow. It also shows how the induction data for updating the 
BOM file is extracted from the PCS file. 

One advantage introduced by the proposed PCS is the 
continuity of the production schedule, i.e., a job order 
Beays alive until it is finished or cancelled. In this way, 
customer orders that were not completed in the scheduled 
@iarter are Carried over to subsequent quarters until they 
are completed. This saves the work of reevaluating the re- 
quirements for end-items when preparing each quarter's 
production schedule. 

The production control system described above can be 
run on the 500 Department ADP system that is used to run the 
temporary MRP system. Weekly runs appear to be more than 
adequate at this time. On-line updates may be required in 
mne future, however. 

It is recommended that implementation begin with only 
transaction updating, even though such information may exist 
mia mechanized form in another part of the system. While 
this may result in extra manual work, it has the advantage 
of simplifying and increasing the involvement of the produc- 


tion control people in the system evolution. 
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Figure 18: The Production Control Subsystem (PCS). 
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E. DATA-BASE DESIGN 

The additional data files that are required for the MRP 
epplication are designed below. 

iene BOM File 

Carrying out a production schedule requires personnel, 
facilities and money (for contracting out repair of special 
components) as well as materiais. The basic MRP technique 
Somputes only material requirements. However, it will be 
desirable to incorporate in the same file the information 
about all required resources and thereby provide a tool for 
comprehensive production planning. 
When considering all resources (except facilities), 

miceinfLormation about each end-item should contain the 
following: 


1. End-item information--including money for contracting 
Gi C . 


2. Consumable materials information. 
3. Labor hours information. 

This implies that the records for each IIC should 
have a tree structure with a root, being a header containing 
the end-item information and two branches, one for materials 
muemetne other for labor hours. Each branch would be a set 
of fixed length records representing either a material or a 
miop's labor hours. Figure 19 depicts the structure of an 


meca’s logical record. 


Pa 





Header 





Shop Trailer 


"Consumable" Trailer 


Pecumewrs cs bOM Data Structure 


Pemesnown if Figure 19, for each TIC there will be 
One Neader, one consumable trailer per consumable item and 
Smememep trailer per participating shop. The information in 
Baem@eeaecr Will allow access to the trailers by either having 
Siememampointer or the number of different trailers. Figure 
Bemcepiets the layout details of the header and trailers. 

Pulamportant £Lactor in designing the BOM is the fact 
that the NARF is involved in maintenance rather than produc- 
Baomeemethne implication of that fact is that instead of having 
a BOM that experiences only addition of new IIC's, as in the 
Case of manufacturing, the file will require changes to 
Pxisting data, namely the replacement factors. Also, there 
must be a distinction between estimated replacement factors 


(representing new or modified items) and items that have 
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already been overhauled. The process of maintaining the 
replacement factor data is described in Appendix D. 
The file will be an index-sequential file with the 

mie being the access key. When only the FIC is known, access 
Meepossible by using the FIC to IIC translation table. Appro- 
metace read/write functions will make it simple for applica- 
mmom programs to access the file. 

inesrmplementation of the shops branch in the BOM is 
Maeependent of the other parts. Since the integration of the 
inventory and production control applications at NARF Alameda 
meme c2oing to take place in the near future, it is recom- 
mended that the implementation of this part be postponed 
until the materials segment works properly and the organiza- 
tion is ready to manage the rest. Deletion of the shop data 
Can simply be achieved by reporting only materials data to 
Bieesystem. This will create IIC records with no shop 
trailers. Because the shops branch will not be implemented 
with the rest of the system, this part will not be included 
in the file maintenance design. 

fee ic to [IC Translation Table 

imemintent of this file is to provide the data for 
translating a FIC end-item identification into the specific 
IIC's that comprise it. The file also allows the opposite 
translation from IIC to FIC. Finally, the file provides the 
relative frequency with which the specific IIC's are expected 
to be inducted. This last element is on hOmeenic mtieal sla 


tion of a production schedule by FIC into an IIC schedule. 
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ities ticewill be composed of fixed length records, 
one record per IIC. The Cee On of the file will be 
such that all records for one FIC will be organized sequen- 
meaiy. Therefore, to find the composition of a FIC, one 
Mas) to access the file and read it sequentially until the 
Mecord Contains a different FIC. Figure 21 depicts the 


organization and record layout of the file. 
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Boure 21: FIC to IIC translation file record 
layout. 
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Smeeother Files 

Peeevle that has not been designed yet is the inventory 
mertus file. This file should contain information about all 
NSN's involved in the requirements forecasting process. The 
Basiest way to get that data will be to get an extract from 
NSCO's MSIR which will contain all records related to items 
stored in the RSS. Using that file will save its maintenance 
by the NARF. Since the information about the quantities is 
mot used by the MRP application, it will be sufficient to have 
a new copy of the file each week or two. Figure 22 depicts 
Meeetyout of this file that will satisfy the proposed applica- 
mon. Any similar structure that is readily available is also 


Batistactory. 


RSS Qty {RSS Qty | Date of jWholesale 
On Hand/On Order} Last 

Trans. 

(Julian) 


NSN | COG | U/I | U/P {Nomenclature 


14 15 ]16 17318 27] 28 





Note: Any other structure that contains these fields is 
fecentable. 





Eeoume 22: MSIR Extract Record Layout. 


Another file that will change with the implementation 
of the proposed system is the MRP forecast file. The infor- 
Mation that was added to the file for current production 
control needs will no longer be required. However, some 


method will still be needed for computing the distribution 
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Meethe gross requirements. Thus, the appropriate new struc- 


/re is shown in Figure 23. 


U/P Installed 
Consumable |Consumable /Quantity 


35 36}37 44 


IIC Scheduled }Total* Extended Price 
Quantity Requirement | per Consumable 


63 65 70 vy 





mereplacement factor - total requirement/(IIC Scheduled 
Meantity * Installed Quantity). 


boeune 25: MRP forecast record layout 


F. SOFTWARE DESIGN 

The software of the proposed system will consist basically 
of the same modules as the temporary system. The differences 
are in the contents and in the set of functions that will be 
used by the different modules. Figure 24 depicts the block 
diagram of the main software modules. 

ieee rile Maintenance 

This module consists of the programs to maintain the 

MoM file and the FIC to IIC translation table. The MSIR is 
not maintained but reproduced whenever needed and the Material 
Forecast file is generated by the requirements generation 


module and updated by queries. 





MRP Production 
Sa Conere ll 


Software Subsystem 





Bile Queries Requirements Subroutines 


Maintenance Generation G Functions 





Figure 24: Software Modules 


a. BOM File Maintenance 
The intent of this module is to update the BOM 
mple with respect to the composition of the end-items, the 
replacement factors of the components, and the labor hours 
mid shops participating in the job. 
The information that will update the BOM will 
Some from two sources:- 
1. Transactions written by the material planners. These 
are intended to introduce new items or to update the 


file after technical modifications have taken place. 


2. Expended materials and labor hours. This historical 
data will be used to update previous data in the file. 


The file maintenance process consists of three 
@eeseas depicted in Figure 25. The first step deals with 
collection of the various inputs (induction data, expended 
materials and labor hours and the transactions written by the 
planners) into one file. This program receives a parameter 


that tells the program the date of the previous BOM maintenance 
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Figure 25: BOM File Maintenance Run 
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Mim and scans the production schedule file for jobs that were 
@empleted after that date. For each completed job the program 
Merces tO the output file one induction data record (type 1 
record as shown in Figure 26) and a set of shop data records 
(type 8 records). These latter records contain expended 

hours by one shop on the specific job. At the same time the 
job number is entered into a table of completed jobs. When 
the end of the production schedule is reached, the table is 
used as a look-up table for extracting expended materials from 
mee DHF and the RSF. For each record that belongs to a job 
mate 1s in the table, the program writes a type 4 record 
Mecquisitioning data). 

Miiemsecond Step simply sorts all inputs and pre- 
meres them for the final step in which the transactions are 
Validated and used to update the file. The sorting is based 
oa columns 1-22 (11C, record type, NSN/shop, date). Ascending 
order will assure that the transactions with header informa- 
tion will be processed first, and later transactions for 
Materials and labor hours (i.e., in the same order that the 
trailers are organized in the file). 

Type 1 transactions are also used to create/add 
new IIC's to the BOM file. Type 3 and type 6 transactions 
provide the additional consumable items and labor hours in- 
formation required to forecast requirements. Types 1, 4 and 
8 transactions are used to compute actual average quantities 


materials and labor hours. 
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Figure 26: BOM file maintenance transactions 








As mentioned earlier, the transactions are sorted 
Meet and by the type of header/trailer the data in the 
transaction is to update. Consequently, the update process 
treats each IIC that has transactions individually, starting 
with creating/updating the header, creating/updating consum- 
able's trailers and finally creating/updating shop trailers. 
The process of updating an IIC begins with reading a transac- 
Meetiat Contains an IIC different than the JIC in the 
Meevious transaction. This causes an access to the BOM in an 
ummm to read the IIC's old data. If the IIC existed, the 
transactions are considered as changes; otherwise they will 
create a new IIC entry in the BOM. In this case there is a 
requirement to have additional transactions with material/shop 
data. 

The process of updating trailers is also designed 
Memireat individual trailers separately (i.e., one consumable 
Or one shop at a time). The induction data transaction is 
Meocessed first and all it does is to save the induction 
@gantity in memory. Subsequently, material estimate trans- 
actions (or shop estimates) simply update the appropriate 
fields in the trailer, whereas for a requisitioning (or shop 
data) transactions the expended quantity is computed and 
divided by the induction quantity to give a new average con- 
sumption. This average is exponentially smoothed (see 
Appendix D) with the old data and the updated information is 


saved in memory. In the course of processing these transactions 


ZZ 








mie program will also have to verify that all data fields 
contain valid data. 

Another function that the program performs is to 
detect exceptional replacement factors. Whenever the differ- 
meee between the old and the new factors is greater than 0.2 
(or any other value that can be selected) the program will 
Mere the data in the input edit and exceptions report. This 
report will have to be checked and, if there was an error, the 
appropriate correction should be made. 

Figure 27 describes the main functions that will 
be performed by the BOM file update program when treating an 
mec. Aithough the flow chart appears to contain many details, 
it is intended as a summary rather than the actual flow chart 
meee program. It must also be remembered that the labor 
Mears Dranch will be implemented at a later time so that it 
matoOo Carly to go into more details than are needed to 
@escribe the general process. 

The complete BOM file maintenance run will be 
meecuted once per quarter. This run will take place a short 
time before the workload conference so that an up-to-date BOM 
file will be available for generating the material require- 
ments. However, runs that just process transactions reported 
by the planners can be run at any time so that new data would 
fot have to wait up to three months before being processed. 


Meekly runs for such purposes are probably sufficient. 
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Figure 27: Updating IIC Data in the BOM File 
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Peeeiadintenance of the FIC to II€ Translation Table 
The maintenance of this file has two goals:- 
1. Update the file with new end-items. 
mumoaate the relative frequency of [IC's. 

The information from the Quarterly Family Tape 
(QFT) will be used to keep track of all existing end-items. 
This file is maintained by ASO and is delivered to users on 
a quarterly basis. It contains one record per IIC and each 
much record contains the FIC to which that [IC belongs. 

The relative frequency of IIC's will be updated 
Meethe induction data. <A record will be provided for each 
Mmiduction, containing the JIC that was inducted, the induc- 
meen Guantity, and the FIC. The input will be sorted by FIC 
moa 11C and by ascending record type ("l"' for QFT records and 
Mm fOr induction data}. 

icmp raniciobceuscdsin Updating the tile 1s to 
Medate all information about a FIC as one unit. Therefore, 
mere ic's that have transactions, their records from the old 
Mile are read into an array in memory. Then the transactions 
update appropriate quantities or open new entries for new 
mic's and at the end of the FIC,updated records are written 
Moa new file. IC's that have no transactions are just 
Sopied from the old to the new file. 

Figure 28 depicts the maintenance run and 


Figure 29 is the flow chart for updating one FIC.- 
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D. Sueries 


Implementation of the proposed system will require 
conversion of the temporary system software to fit the new 
data-base. The use of the MRP subroutine will simplify signif- 
icantly the query program and will usually require a simple 
"driver'' program that will prompt the user and translate his 
inputs into appropriate MRP subroutine calls. 

To facilitate use of the system, "query numbers" will 
De assigned to each type of query. They will allow the user 
mo Choose the query type dynamically. In the selection mode 
the system will display all alternate queries available for 
mse and let the user specify his choice. This will then cause 
Mranching to the appropriate module that will retrieve the 
requested information. 

Beoure 30 depicts the block diagram of the query 
module. 

3. Requirements Generation 

Mims module will be significantly different from the 
One in the temporary system because the proposed requirements 
generation program will consider job orders that are already 
in process and because the use of the MRP subroutine will 
Simplify the program. 

The generation of the requirements will consist of 
Beveral steps, as shown in Figure 31. The first step scans 
the production schedule file to extract and build a list (in 
memory or as a temporary file) of all job orders that will 


be worked on during the coming quarter. This means that an 
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sntry will be opened for each job order whose planned period 
mes in the coming quarter and whose status is blank, "W" or 
Meee Each such entry (or record) will contain the job order 
Menich contains the IIC) and the scheduled quantity. 

ites next step will use those job orders as a table to 
@eeract from the DHF and RSF the materials that have already 
Meee xpended in Continuing job orders. The output of this 
mep 1S the Expended Materials file. 

The third step is the actual preparation of the MRP 
forecast file. In this phase the program issues calls to the 
(RP subroutine and transforms the output from the subroutine 
mo records with the structure of the MRP Forecast file. 

Atter the material planners finish updating the MRP 
forecast file. the computation of the requirements for each 
sOnsumable item is performed. To do that, the intermediate 
‘ile that subroutine MRP needs is regenerated from the final 
mee rorecast file and both the intermediate file and the 
ixpected Materials file are input to the program which issues 
Meterminating call to subroutine MRP. The subroutine then 
ses the proposed model to generate the final requirements 
Meeecast. This output is formatted into RSS level setting 
cransactions (AOA transactions). 

4. General Purpose Subroutines 
The MRP application involves several functions that 


vill be performed by several programs. [It will be very useful 


‘They can modify only the "total requirement quantity" 
[leld--see Figure 23, columns 66-69. 
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to have those modules shared by the different programs, thereby 
saving programming effort and assuring consistency. 

A set of such functions are the read/write functions. 
The application involves several variable-length-record files 
which may present a problem to novice programmers. The prob- 
Hem can be solved by a set of I/O routines. Each routine will 
MeritOrm either read or write. It will be called with param- 
eters that will specify the program's need and will return 
(Or write) a complete logical record or a required header/ 
trailer. Some additional work can be saved by having the 
Various data structures in software libraries. Those struc- 
tures would be copied by user programs and would save the 
definition by each one. 

Emetnes subroutine that will be required is a sub- 
routine that accepts the mean and variance of a random var- 
lable that has a Normal distribution, and a desired cumulative 
probability and provides the value that satisfies that proba- 
Melity. This function would not have to be written by local 
personnel but can be bought from software vendors. This 
function is required for the application of the proposed 
model. 

Another required subroutine is one which identifies 
the IIC that is being overhauled in a given job order. The 
Mic is contained in the job orders but its position is dif- 
ferent according to the production program the job belongs to. 
By maintaining a table of the positions of the IIC in various 


job numbers, one can easily identify an IIC from a job order. 


5 





mers tUnction will be needed to allow access to the production 


schedule or to the BOM file when only a job order is given. 


mee OL STEM CONFIGURATION 
The intent of this section is to identify the computer 
cesources that will be required for running the proposed MRP 
@epeication. the sources that were utilized in estimating 
the resources are: 
m The information about the temporary MRP application. 


2. Comparison of complexities of the existing and proposed 
software and data-base. 


Meer ecrsonal experience of the author with similar systems. 
Maeeemanalysis takes into account an annual file size and 
Jrocessing growth factor of 10 percent and assumes a useful 
mere period of ten years [26]. 
ieeeeon-Line Storage 
On-line storage is required for the data-base, work 
@reas, and software libraries. The last two elements can be 
ignored here because of their relative small size and also 
decause they are shared by other applications. 
Table III shows estimates of the net sizes of the 
Various files. When considering inter-record gaps of 30 bytes 
gid allowances of 10 percent for overhead and indices, the 
required storage becomes (118924 + 30 x eo”? oul ew NERS 


When the future growth during the useful life of the system 


is included, the requirement at the end of ten years becomes 


Bu? xX ae) ~ 488MB one (opglemialt= Sy eeneelers 5 
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File Name 


prc to LIC 
Translation 
Table 


MRP Forecast* 


MSIR Extract* 


Production 
Schedule* 


Total 


TABLE ITI 


File Sizes 













Net Size 
(K-Bytes ) 


"Record'' Name # of Records }|Record Length 


(Bytes) 









TIC header 


Consumable 
Trailer 


Shop Trailer 170,000 


“a - i 


Consumable 1,000,000 77,000 
Record 
NSN Record 40,000 2,280 


20, 000 


14,000 
700,000 


















FIC Header 






Job Order 42 les 


ira wler 
Shop Trailer 340,000 7,14 


| 
2,306 , 000 =~ 118,924 


28 , 000 





k Numbers of records were inflated to represent required capacity 


at war time. 
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Meas Storage quantity is less than 30 percent of the 1200 MB 
disc storage that ASKARS will have as a minimum [22:3.3.8]. 
oer -Line Storage 
The required off-line capacity imposes no constraint 
except to tape drives. Two tape drives will allow copying of 
files, taking back-ups, and running the programs that will 
usually have input (transaction) tapes. 
3. Main Memory 
Main memory is required for programs (and their [I/O 
buffers) that are run simultaneously. Since file maintenance 
@eaeaqueries would not run concurrently, main memory require- 
ments are computed for the file maintenance module and the 
general purpose subroutines. As Appendix C shows, the length 
of those modules is 2000 + 450 = 2450 high level language 
statements. Assuming an average of 10 machine instructions 
per statement and an average of 6 bytes per instruction, the 
total main memory amounts to 2450 x 10 x 6 = 147000 Bytes. 
When adding buffers for the BOM file (= 8.8KB), the production 
Meredule file (5 KB) FIC to IIC translation table (35 bytes) 
and transactions (80 bytes), at least 165 KB are needed in 
addition to the memory resident operating system modules. 
However, it must be noted that systems whose operating system 
provides virtual memory may utilize less real memory. 
fee Processing Time 
When computing processing time, one has to distinguish 
between three different modes of operation during a quarter, 


each of which requires different processing Capaciat ess 
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The highest capacity is required when the mainte- 
nance of the BOM file takes place (once per quarter in the 
third month) and when the MRP Forecast file and RSS level 
Meeting transactions are generated. A lower capacity is 
Bequired for maintaining the Production Schedule file (at 
least once a week). The lowest, but most frequently required 
Mapacity is for the queries. 

iis imposes a changing load on the system and it 
meet require timing the execution of various programs to 
prevent temporary peak loads. 

jiieestimating the total processing time for MRP and 


PCS, the following assumptions are made: 


ime) Machine instructions per statement. 
2. Average clock pulses per instruction = 12. 
Sec lock rate = 3 MHZ. 


feeeburing file maintenance, one-half of all statements 
are executed for each transaction. 


aeeburing queries, one-fourth of all statements are 
executed once per query. 


Ge im report generating type programs, each statement 
Mmemexecuted once. 


Applying assumptions 1] through 3 gives an average 
statement execution time of HO xl ex 3 = 40 usec. 
When using this average execution time with the input 


rates from Appendix B, the program sizes from Appendix C, 


and the processing capacity as shown in Table IV, and when 


oo 





er ees eg ene Ca eee a ee en ee ee eT 


O02 i 
+ 00SZ + 0002 + 0008 SaTian 


000 ¢ S,NSN 00002 
00S‘TS O0¢ 000 ‘SOT 
orice = 000°SZ + 000‘0¢ 


OS%- S6S AS TOCSY CSO I 
= O00) OOO te + eine nic 





= WUE ee 10S ae 








uoOT}eIDUdN 
SUOT}OBSURL] SSY 











uOTI PI9IUDNO 
SJUuDUdAITNbday 











QJIUBUDZUTBEW SDd 





sdueud UTR 
9Tqe] uot eTSuel] 
Oli OF 






00S‘LL 
= 005° + O000‘OP 











000‘06 
= 00SZ + 0000S + OOSZLE 





IDULUdIUTR] 
9TtH WOd 








(Arant 10) 
uoT}OeSUPL, 
lad sjzuows eis 


(000T X) 
110 a9d poaqynsoxg 


S}UuUdW9IeIS TRIO] 





(sotionh 10) 
La,JLenh 19q SuOoTJOeSURII 








uny SUTSSOD0I1g 









JTIBAaGB’) UuUTSSIJIOL 


AI HTavVi 


140 





@eplying the 10 percent annual growth factor, the total 


guarterly execution time during the tenth year of operation 


amounts to: 


MemimeeiG: x 40 x 10° x == x (1.1)? = 427 hours per 





ee Guar ter 
eee cents a= ; aos, 
Gtr Stat. sec 


Baring the first year of operations the system will 

Beecre Only S.00 hours per quarter. 
5. Conciusions 

Mies resources that are required for running the MRP 
application are relatively small. The computations above have 
Mmeeen into account not only the MRP system but also the PCs. 
emeenciuding future growth, the processing time does not 
meeretity devoting a computer to this application. 

The conclusion is that the application should be run 
OM an existing system and the system that appears to be 
@eprOpriate is ASKARS. The reasons for selecting ASKARS' 
computer system are three-fold: 


1. The MRP system plans materials which are carried and 
later handled by ASKARS. 


MePASKARS is a redundant system and therefore the addi- 
tional load on the system would be insignificant. 


3. The ASKARS system will hopefully have skilled ADP 


personnel (as opposed to the PDP 11/70 on which the 
temporary system runs) that could handle such a project . 
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meee Ools AND BENEFITS 

The purpose of the following analysis is to compare the 
costs involved in implementing the proposed system and to 
Seplore the benefits it will provide. 

The costs involved in implementation of the MRP system 
are of two types: one-time development costs (software 
development) and recurring costs for software and hardware 
maintenance, supplies, personnel, and payments for computer 
time. Although ASKARS' processing and peripheral equipment 
have already been accounted for ("'sunk cost'') we will assume 
in this analysis that there is a capital cost associated with 
using the MRP application in ASKARS and that it can be computed 
meeoraing to the proportion of CPU time the MRP uses relative 
to the total CPU time available. We will also assume that 
mae annual depreciation cost of this equipment is 10 percent 
of the purchase price. Consequently, the annual allowance 


mor hardware is 


ie Mee, 10x [T,/T,] 


where: HC = annual allowance for MRP hardware costs 
PC = purchase costs of the complete system 
Ty = CPU time for MRP. We will assume an average 
of 10 hours per quarter (see section G.4 of 
ies Chapter). 
T. = total CPU time available per quarter. Since 


there are two processors, 


qT, =o Ome = 1 1a) Owns. 


Since the procurement of the ASKARS system is now in the 


bidding phase we will assume that the cost of the ADP equipment 
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Mesvepcrcent of the total cost of the ASKARS syscem. The 
Mercer 15 Estimated to he $2,513,500 [26]; consequently, the 
cost of the ADP equipment in that system would be approxi- 
mately $1,257,000. Using these figures, the hardware costs 
would amount to less than $1000 per year. 

Allowing 10 percent of that amount for hardware mainte- 
Mance, the MRP's share of hardware maintenance costs will be 
@pproximately $100 per year. 

software maintenance will be assumed to require one 
programmer and 1/6 of one analyst (based on development per- 
sonnel). In addition, the system will need two clerks for 
handling inputs and outputs. Using an average annual salary 
of $30,000 a year, including fringe benefits, the personnel 


costs for software maintenance and operations would be: 


(1 + 1/6 + 2) x 30,000 = $96,000 per year. 


Mien using the software development times from Appendix 
C and the above annual salary, the development and training 


expenses amount to 


oe 14,2 + 0.2 + 1.0 + 8.0 


s ) x 30,000 = $247,250 


( 


To that we have to add processing time of approximately three 
months during the development period (HC x 4/2 = 530) to get 
a total of $247,580 for development costs, or approximately 
$25,000 annually to be added to the recurring costs. When 
adding all these costs, we find that the annual costs of 


Tunning the system are $122,100. 
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iiespenefits from implementing the system are more diffi- 
Mert to measure, although relatively easy to identify. The 
system will provide the material planners a good data base on 
Mmorch they can base their decisions. It will also save them 
time by providing the necessary reports and inquiry capa - 
bilities (although this is not intended to totally replace 
their being in the shops!). The system will also provide a 
better requirements forecast and thereby improve availability 
Of materials for repair and availability of ready-for-issue 
meems that would not be delayed in the process of repair. 
Another area of savings is in workers' time. Because of 
improved availability of materials, work stoppages are ex- 
mected to go down, thereby reducing the need for "backrobbing" 
mec. , removal of parts from an aircraft/component for use on 
another aircraft/component with an earlier scheduled comple- 
mron date [(21:16]). 

Another very important advantage of introducing MRP is 
the fact that the improved forecast should lower the amount 
Se money tied up in inventories and should release that money 
mereuse elsewhere. 

The factors that have been mentioned above gave a quali- 
tative description of the benefits; quantifying some of them 
Mmectlarify the description. Dutene= ene wpe vod 1 Aprr. 1978 
thru 31 March 1979 NARF Alameda's work centers charged 21,186 
production delay hours to backrobbing. These hours represent 
a cost of more than $860,000 [21:16] per year. Expenditures 
on material planners’ salaries amount to approximately 
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Meee x 50,000 = $3,660,000 a year. Saving 1 percent of their 
‘ime represents $36,600 per year and the system will doubtless 
save more than that. When adding to that the money expended 
yy the NARF on materials--being almost $60 million in 1978 
meep--it becomes obviously clear that the annual benefits will 
xxceed the $122,100. 

Mioetier aspect that is worthy of consideration is that 
she MRP system may also be implemented at other industrial 
Merrvities in the future so that the initial investment in 
ms system can be expected to reduce the investment in those 


mature systems. 


IMPLEMENTATION PLAN 

Implementation of the proposed system should consist of 
mie tollowing phases:- 

meeestablishing a development team. 

2. Software design, programming and documentation. 
3. Conversion of the data base. 

Mmemcesting. 

Meeiraining and parallel operation. 

o. Post implementation reviews and improvements. 

The development team should consist of systems analysts, 
‘rogrammers and user representatives and should be responsible 
for preparing a detailed implementation plan, detailed system 
jesign and implementation of the system. This thesis would 


Irovide the team with design guidelines. 
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Mitemvarious activities that take place in each phase are 
@escribed in detail in Appendix C. Figure 32 gives anticipated 
meojyect schedules for implementation of the system as well as 
the system development activities and human resources that are 
needed in each phase. 

Miem going into actual implementation, it will be very 
Important to keep in mind Woolsey's [24] "Ten ways to go down 
with MRP."" Among others that he mentions, the following should 
be regarded carefully here: 


Mummy involve the highest level of management in defining 
mem hands-on’ side of the system." 


fee Don't run the system in parallel, just shut down the 
manual system and turn on MRP." 


See Don't clean up your bills of materials, you know they 
Beceright." 


meme Don't require sales to take responsibility for screwing 
Mgeetne master production schedule." 


5. "Install the system as a surprise to Production and 
pares," 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


The MRP technique is designed to use the fact that the 
Meee trial requirements in a production or maintenance oriented 
environment are driven by the production schedule. However, 
the technique will only work if an accurate BOM and production 
@enedule exist. 

The system that is proposed in this thesis is designed to 
provide the means for developing and maintaining an accurate 
data base. Additionally, it provides a model that will use 
that data effectively to generate a realistic materials fore- 
Gast. 

The analysis of the temporary MRP system and its develop- 
ment as well as the design of the system proposed in this 
thesis have identified some problem areas that will have to 
be considered carefully in the course of implementing both 
Of the systems. These problems are: 

ieoystem Development 

The process of developing any system requires analysis 
and design by a team that has the time and competence to do 
the job. The implementation of the proposed system requires 
assignment of a team that will be responsible for reviewing 
the temporary system, preparing the detailed design for its 


meccessor and implementation. 
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fee lanning Horizon 
The proposed system was designed to meet the constraints 
imposed by the current budgetary process and the quarterly 
preparation of the production schedule. This implies that the 
Socem does not have the capability to forecast long run re- 
merrements, nor can it provide all requirements, a procurement 
meaa-time ahead to assure that all materials are purchased so 
meat all scheduled jobs can be accomplishable. This situation 
@am Obviously be improved significantly by developing long run 
Broduction schedules and trying to stick to them as much as 
Possible. This appears feasible for at least the engine and 
components programs that represent a major part of the work- 
Mead schedule [21]. 
Seeeerequency of Requirements Generation 
Peoeeine of the RSS stock levels is currently limited 
Meonce per quarter. This corresponds to the current frequency 
of determining the production schedule. [It may be eventually 
useful, however, to regenerate the material requirements and 
Beset levels on a monthly basis, thereby decreasing the influ- 
Mee Of the random part of the forecast. However, the system 
should be used at least for one year with the present frequency 
to determine its performance before any changes are made. 
meecoOordination with the UICP 
The MRP forecast cannot be effective if the UICP 
System does not assure the existence of the required materials 
within the wholesale system. Since the problem is related to 


all NARF's and not just to Alameda it would be useful to 
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Goordinate the operation of both systems so that the UICP 
could use the long-run forecasts from the MRP system as planned 
program requirements. 

feeaoKARS and NISTARS 

Although these two systems are being developed inde- 
pendently, there will undoubtedly be a need for communication 
between the systems. NISTARS will provide the storage space 
for the RSS and will also maintain a data-base which contains 
Meeat information for the NARF's day-to-day operations (for 
@eample, inventories on hand). Therefore, setting up an 
@eproOpriate interface between the systems to allow direct 
access of one system to the other's data-base can simplify 
file maintenance in general and service to the users in 
merticular. 

OueeeiC's and IIC's 

The practice of preparing the production schedule by 
FIC introduces uncertainty into the process of planning material 
requirements and complicates the maintenance of the MRP system. 
M@eansition to planning by IIC will make the whole process much 
more accurate and efficient. 

A rather different subject is the relationship between 
ASKARS and MRP. It so happened that the ASKARS system will 
become operational at the right time for implementation of the 
proposed MRP system. However, the interaction of two new 
Systems may be very disastrous and therefore it is recommended 
that the actual implementation of the MRP system be delayed 


until most of ASKARS' “birth problems" have been resolved. 
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iias delay time should be utilized to get better acquainted 
With the MRP system through the experience with the temporary 
System and to purify the data-base. This period should also 
be used for further analysis of the parameters needed for the 
proposed model. 

Pal@ener area that is related to the MRP system and 
Bequires further analysis is the policy of overhauling complex 
p@eemtetems, especially aircraft. The current policy is that 
whenever an end-item is overhauled its repairable components 
are also overhauled and placed back on the same aircraft. 
aieemaclays the completion of the job and calls for inductions 
Pemeemoonents separately from the regular induction of such 
BolmeementsS being repaired and placed in the supply system. 

The MRP system would operate best if repaired components 
from stock were used in the aircraft overhaul and components 
from the aircraft that needed rework were returned to the 
Supply system as non-ready-for-issue inventory. The advan- 
meemmer Chis policy with respect to MRP is that it provides 
more accurate values for the replacement factors. As men- 
tioned earlier, it is desired to make the decision about this 
mubgect before conversion to the proposed system to save later 
changes in the BOM data. 

mnomappl!ication of the project system to other activities, 
it appears that the model may be appropriate for other indus- 
Mirae activities to use. However, any action in that direction 


moma probably not take place before the model proves its 
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- 


effectiveness at NARF Alameda. Much will undoubtedly be 
learned which would serve to save time and effort for other 


applications. 
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NEPENDIX A 


MS CreohieGinn UA weo- or PILES [18 | 


Master Stock Item Record (MSIR). This is the master 
miventory status file. 

Planned Requirement/Reservation File (PR/RFS). 
Receipt/Due File (R/D). 

Requisition Status File (RSF). 

Wemand History File (DHF). Together with the RSF, 
represents the demand history. 

Address Master File. (AMF). 

Job Order File (JOF). 

Master Employee Record (MER). 

Receipt History File (RHF). 
Transaction/Reconstruction File (TRANSRECON). 


Demand Master File (DMF). 
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SUPPORTING DATA> 


1. Supporting Data 


The information to follow is required for estimating the 
Bize Of files, processing times, and the required storage 
resources for the proposed system. The estimates are based 
On analyses of the present inventory system at NSCO and the 
GempoOrary MRP application. 

General Data 

meproximate number of active FIC's = 10,000 


Approximate number of active IIC's = 14,000 


Maximum number of IIC's per FIC = Sd 

Average number of consumable NSN's per IIC = 50 

Maximum number of consumable NSN's per IIC = 1,200 
Average number of shops participating in IIC overhaul = 12 


Maximum number of shops per IIC (all that exist) = 150 
Number of active NSN's (used by the NARF) = 35,000 


member Of active job orders = 28,000 


Number of material planners wae 


m transactions Volumes and Processing Frequencies 


Table B-1 describes the different software modules, and the 


type and volume of transactions processed by each module. 


Obtained ELON PetmsOnd Leiber Vt ewsewitineleDR WaP. Benetiel, 
500 Department, NARF Alameda, February 1980. 
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Transactions, Volumes and Processing Frequencies 
for the Proposed MRP System 


Name of Number of 


BOM 


Induction data 









File maintenance 
150,000 per year* 
Requisitions 200,000 per year* 


Estimation transac- 
tions 


BOM update run 


POS O0 0S mer satiate i 


Once per quarter 








Pee lO. 1 1C 
Translation Table 
GCEi wt aaisaet toms 40,000 per quarter 
Induction data 


Table update 


PU ,0VUe per year 


Once per guarter 


























































oS Status transactions ie OiempietT Clair ter 
Expended hours 
transactions ee Po eet 
File maintenance run} Weekly run 
Production schedule Monthly 
este 
EXC Cpe HoOlmene One Monthly 
Queries S00 per quarter 
Queries Inquire BOM by IIC quarter 
Inquire BOM by FIC PeaOOU per quarter 
Inquire MRP foxrecasimae, 100 (vereqmaneer 
Modify MRP forecast quarter 
Requirements Expended materials 30,000 per quarter 






generation transactions 







"Raw'' material 
requirements 


RSS level setting 
transactions 





Tomueos per quarter 





APwUO epee. Cuarter 


*The figures are inflated to represent overload during war time 
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SOFTWARE DEVELOPMENT 


1. Software Development Activities 

The development of the MRP software will involve the 
Beblowineg activities: - 

a. Design and Programming 

Detailed specifications have to be written for each 
meme module, file and processing run. These specifica- 
tons Will then be translated into computer programs which 
Will be later tested to assure their compliance with the 
design. 

be «Conversion 

This phase involves preparations and actual conver- 
Peuemecerom the temporary MRP system to the proposed applica- 
mone ro dO this, special programs will have to be written 
momeonvert the old data base to the new structure and to 
insert default values in those fields that did not exist 
before. 

Because of the nature of the application it is possible 
and very desirable to operate both systems in parallel for 
one quarter. However, when the final system is accepted it 
would be appropriate to have a short (say, two days') break 
in running the application. This period would allow all the 
transactions in the old system to be processed and the "live" 


conversion to take place. 


ro 
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me Lesting 

This phase includes testing of individual software 
modules, programs and processing runs. Different transaction 
paths and options of the system should be tested to make sure 
that it all works as expected. 

The end of this phase involves a user's acceptance 
test during which the user tests the system, and then accepts 
responsibility for normal operations if the test is success- 
fully passed. 

weer arallel Operations 

mere che Old system 1S still running, the new one 
Should run in parallel. This will allow the new system to 
be checked out before the old system is shut down. This 
phase also allows the users, and especially the material 
planners, to get acquainted with the new system, learn how 
to inquire and how to use the system's output. 

e. Documentation 

Documentation of the system should be done during 
the entire course of the project. At the early phases, the 
emphasis should be on documenting decisions and reasons for 
fPeeeeime specific options or procedures. In the later 
stages the emphasis should be on documentation of the soft- 
ware, data-base, input, output, and use of the system. 

The documentation should cover all modules, the 
interfaces between the modules and interrelation between the 


modules. Operational manuals should be provided describing 
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regular operations and actions to be taken when irregular 
events ("bugs") occur. 
fee training 
mivOolvement of the users in the early design stages 
will pay off when time for training comes. However, training 
should be provided to all users and people that are involved 
Mimeiiming the system (operators, 1/0 clerks) to assure that 
they know how to handle the inputs and how to use the outputs 
and the services the system provides. 
g. Post Implementation Reviews 
After the system goes into normal operation, it would 
be very desirable to have at least one or two post implemen- 
tation reviews. These are meetings of the development team 
and the users in which problems are brought up and discussed. 
Mtetmere are problems, the group should identify its source 
eiceiimd a solution that will satisfy the users. However, it 
is advantageous to collect requests for small changes rather 
than implementing each one as it comes up. In addition, these 


enameges Should be examined to see if they are really needed. 


Z . Development Times 


The cost of the software development will be based on the 
Mize and complexity of the different modules [25]. The 


following productivity standards will be assumed in this 


Brocess: - 
1. Programming -- Fifty source, high-level-language state- 
ments per programmer per week (for simple level 1 
complexity programs). A statement in a simple program 


meek be the ''standard unit." 
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feeeecing -- 150 statements of complexity 1 per programmer 


mem week. 

Peeocumentation -- 15 percent of total programming and 
testing time. 

4. File Conversion -- approximately the same as file 
maintenance. 


Seeeaining and Parallel Operation -- two training days 
Meeriainussr/oscrmtct 
Table C-1 shows the derivation of the total size of the 
software (in ''standard'" statements) and allows derivation of 
the software development times as follows:- 
1. Programming time = 8650/50 = 173 man-weeks = 44 man-months. 


2. Testing time = 8650/150= 58 man-weeks =~ 14 man-months 
(8 programmer man-months and 4 analyst man-months). 


3. Documentation time - (44 + 11) x .15 = 8 man-months. 
4. File conversion time = (2250 + 300 + 1500)/50 ~ 81 man- 
weeks ~ 20 man-months (15 programmer man-months and 
5 analyst man-months). 
5. Training and parallel operations time involves: 
a. 0.5 programmer man-months. 
fee. Z analyst man-months. 


G. 0.2 operators man-months. 


d. 1.0 clerk man-months. 


ineeddition to that, analyst time 1s required for prepar- 
ing the detailed specifications for the MRP application. 
mieeaeon the time that this study took, it 1S estimated that 
3 more man-months of analyst time are required. 
Padang together all elements gives the following times: - 
1. 75.5 programmer man-months. 


“eeloe2 analyst man-months. 
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TABLESG= 4 


Software Size 


Source Standard 


File 
Maintenance 







Bev iaoue eda t 
EXtract 
Update 


relies te LIC trans 
lation table 























EXCrace 
Update 

Bes input dit 

Update 


order 


1 


Hueries Query "Driver" 100 2 
‘Query BOM 100 Z 
Query MRP 
forecast oe : 
- MRP 500 3 
p£orecast 
equirements; Extract inputs 1 50 
Generate forecast 2 500 
Reformat output 1 50 
| 
Generate l 100 
transactions 
Subroutines | MRP subroutine 2 300 
functions 
Read/write 
and report eG Bis Z 400 
generators . | 
Pie rerom 700 1 | 100 








Beeeue2 Operator man-months. 
4. 1.0 clerk man-months. 


5. 8.0 material planners man-months (based on 120 planners). 


These figures imply that the implementation of the system 
in a period of one year requires the employment of six pro- 
grammers and one systems analyst. However, because the load 
msemot cqually distributed during the year it may well happen 
that at some times additional programmers (or overtime) and/or 


systems analysts will be needed. 
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APPENDIX D 


UPDATING REPLACEMENT FACTORS 


miemoecplacCement factor represents the proportion of a 
consumable item that is expected to be replaced when the end- 
item that includes that consumable is being replaced. The 
replacement factor is expected to change during the useful 
life of an end-item because of: 

feeeeing of the item; 
2. Changes in maintenance policies; 
3. Estimated replacement factors found to be in error. 

Consequently, there are two ways to update the replacement 
Pactor. 

ieee by Iransaction 

The transactions that are submitted by the material 
planners (see BOM file maintenance) will set the "estimated 
mepbacement factor'' field in the BOM file to the value reported 
mm the transaction and will update the “estimator code" and 


"date of last estimate'' as well. 


2. By Actual Replacement Information 


During the BOM file maintenance run, actual replace- 
Ment factors are computed. The actual replacement factor is 
the ratio between the total quantity of the item replaced in 
meeriaal of a certain IIC and the total installed quantity 


of that consumable in the whole quantity that was inducted. 
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miss new replacement factor will be used to update the 
maetual replacement factor." 

merous methods exist for updating information such 
as the replacement factors. The most simple would be to com- 
pute a weighted average of the new and the old replacement 
maectOrs where the weights are proportional to induction 
quantities. A variation on that would be a simple moving 
average [29]. This method is utilized in the temporary MRP 
Soret ihe Exponential Smoothing method is still another 
method Often used in such cases. Its big advantage is that 
zit needs no other data but the old and new factors and the 
smoothing constant. 

Rerecasting usually involves a start-up problem. 
The information that is initially available is an estimate 
aiamene problem is how to phase it out and replace it by 
actual data as it becomes available. The intent of the pro- 
posed procedure for updating the replacement factors is to 
Mepiaze information of both actual and estimated factors and 
to gradually phase in actual data so that as soon as suffi- 
cient actual experience is available the estimate will be 
Memored. To do that, two separate fields are maintained in 
Pacn ‘consumable trailer in the BOM file, one for the esti- 
mated replacement factor and the other for the actual factor. 
mamadditional field is used as a counter of the total induc- 
Pion Gguantity on which the actual replacement factor is based. 


The contents of the estimate field are derived from 
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Bransactions, each new estimate for an IIC/consumable over- 
mtamme the previous one. The actual replacement factor is 
memmco zero when the trailer is created and also whenever a 
Meweestimate is processed. At the first time an actual 
factor is computed, it will override the zero. In subsequent 
updates, a new actual replacement factor will be computed 


using exponential smoothing as follows: 


IF Oe 92 .P ae ole: 


N+] N A 
where, 


Pe 1s the new "'actual'' replacement factor, 


Fy is the old "actual" replacement factor, and 


Fy 1s the actual replacement factor computed 
iOM el aS t aCiidekhe ls esiea ait ae 


The determination of the replacement factor to be 
used by a program will be done by a subroutine. This sub- 
routine will return to the calling program the replacement 
factor which results from the information in the fields con- 
taining the estimated factor, the actual factor, the date of 
estimation and the total induction quantity. The algorithm 
for determining the replacement factor is as follows: 

ime nO actual factor exists, return the estimate. 


2. If an actual factor exists and the date of the estimate 
is more than a year old, return the actual factor. 


3. If the above conditions are not satisfied, compute the 
factor to be returned by exponentially smoothing the 
estimated and the actual replacement factors. The 
coefficient, a, to be used will be determined according 
f@omene total induction quantity. For example: 
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Pee the induction quantity is less than 10, a = 0.1; 


beer it the peg On quantity is in the interval 
feed, 100), a 0225; 


meet the induction quantity is greater than 100, a = 1.0. 
The various parameters mentioned above, namely, the 
Berroa berore the estimate is totally phased out, and the 
intervals of total induction quantity for the variance a 
Values, may have to be "tuned-up" after some experience is 


gained. 
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PeRtReR DISCUSSION OF THE PRM-MRP MODEL 


The Impact of a Budget Constraint 


Suppose that a budget constraint exists and assume that 
miemLous replaced items are all purchased. In addition, 
assume that after the 100% replaced items have been purchased, 
a limited remaining amount of money from the NSF is expected 
to be available to buy the items replaced less than 100% of 
the time. If we denote this remainder as B, then our con- 


Seraeme on funds results in 


where C.-Y; momtne total cost of buying ie Unees or LTepars 
merteNO. 1. 

If we solve for the individual values using equation (5) 
it is possible that these values will result in 


g 


: a? B 


1 


hms 


rh 
However, this may not always be true and therefore it is 
appropriate to determine these "unconstrained" values of the 
different y's and test them against the constraint. If, 
indeed, the budget constraint is satisfied then we have the 


correct optimal y values. 
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If the budget constraint is not satisfied, the technique 
of Lagrange can be used to get a modified form of equation 


(5); namely, 


h 


T) KC 


- Coe ®, mete ke ean 
207) = : 


(9) 
The approach is then to introduce trial values of @, deter- 
mine the resulting set of y values using equation (9), compute 


the associated sum 


and compare it with B. If the sum is less than B the value 
Of @ should be reduced; if the sum is still greater than B 

the value of 9 should be increased. The search terminates 

when a value of 8 results in the sum being equal to B. The 
associated vie values are the budget constrained optimal 


quantities of the m repair parts to place in the RSS. 


ime >ouceget Constraint APD EO pmrate 4 


The model developed above assumes a static situation in 
which the production schedule and the budget constraint are 
given. However, imposing both constraints in advance may 
have an adverse effect on the ability of the NARF to meet 
that schedule. It may well happen for a given component 
undergoing repair, that the items with 100% replacement will 
be available in stock whereas other items (for which P < 1) 


would not be there. Consequently, what may happen is that 
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instead of having complete kits of parts required to complete 
Secemenere will be only “partial” kits, i.e., all the parts 
replaced 100% of the time and some of those where p< 1.0. 
maeouwech a Case there is no way in which a job could be con- 
meetea. Moreover, those parts that are in stock may remain 
useless because of the shortage in other parts. 

iresconclusion is that the proper way to go is to schedule 
jobs into the NARF so that the budget will be sufficient to 
meovide all materials predicted by the model thereby, in fact, 
Soomeime that the constraint 1S not active. However, it might 
memmeorcal to prepare a reserve of job orders for the case 
that actual consumption was lower than the forecast. The 
proper way to provide protection against such an event 1s to 
induct additional quantities of the items that have been 


inducted previously. 


Reducing the Number of Scheduled Jobs 
because of a Budget Constraint 


To avoid the problems described above, it would be 
mammal to schedule jobs so that their material requirement 
would not exceed the budget vice changing the quantities of 
the materials placed in stock. To meet that goal, the orig- 
yale list of job orders should be split into groups of jobs, 
each group containing jobs of some priority. Then, the 
algorithm should be applied to each set of jobs to determine 
the budget it requires. When this step is completed, one 
mane determine which jobs can be scheduled so that their 


material requirements would not exceed the budget, or on 
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miceewother hand, determine what increase in budget will allow 


the scheduling of some additional jobs. 


The Back-up Stock (w) from the Wholesale Supply System 


w is a variable quantity. Although the quantity of back- 
up stock is known at the start of the quarter or when planning 
occurs, the amount available at the time it is needed depends 
among others, on the demand the item experienced from other 
Heuivaties during the time from the start of the quarter until 
Mmememmle when the shortage occurred. It may be appropriate 
to use as w the amount of the item prepositioned as war 
reserves. However, this assumption requires having a per- 
mission to actually use that stock in the event that a short- 
feemeecurs in the RSS stock and the quantity in the regular 
wholesale supply is insufficient. 

Perhaps a sensitivity analysis will provide guidance as 


to the appropriate assumptions to make about the value of w. 


Which Constants to Use 


The model requires the following constants: 


C, meme Gecessing costs 
Cy = Holding costs 
T° Siertage cost for item obtained from local 


wholesale supply 
- Shortage costs for items obtained somewhere else 


fee- ourplus cost factor 


It is logical to assume that these constants have specific 


values for each item used in repair of a component. It is 
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h 
it may as well be logical to apply these constants to groups 


relatively simple to determine the values of Cy and C, and 


of items of similar nature. This is not the case, however, 
with Tr, 5; and k. The shortage cost depends not only on 
the item that is not available but also on the specific 
circumstances of a given job that requires the part and on 
milememmecumstances of other jobs. That is also true for k. 
Consequently, Ty Mo, and k may vary from job to job, from 
part to part, and even from time to time for the same job/ 
part. It may be useful to note that k can be viewed as the 
"knob"'' that adjusts the surplus cost [see equation (9)] in 
much the same way as is done in the UICP model where the 
"knob" is the shortage cost. Also, when a budget constraint 
is imposed, it may be viewed as increasing the value of the 
surplus cost resulting from k, causing a solution for y more 


ieeavor Of a shortage. 


Pragmatic Aspect 


Maintaining the different constants for each item and, 
in particular, having it done by the NARF, would be prohib- 
itively complicated. The system may become significantly 
more simple if the constants could be determined for groups 
of items rather than for each item. It seems logical to begin 
by establishing values spanning groups of items (and keeping 


those constants in a table that will be shared by different 


application programs). 
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